Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
Andriy Gapon
avg at FreeBSD.org
Mon Dec 5 22:02:21 UTC 2011
on 05/12/2011 19:58 Alan Cox said the following:
> On 12/05/2011 07:56, Andriy Gapon wrote:
>> Pages should be marked busy only for some special occasions, wired pages are not
>> normally busy; the correct explanation is quite a bit longer than this, the
>> comment in the code explains VPO_BUSY as "page is in transit". Right now this
>> flag doesn't seem tom affect vboxdrv code but it may lead to surprises when some
>> parts of code that are incorrect now are re-implemented properly:
>> http://article.gmane.org/gmane.os.freebsd.devel.emulation/9297
>
> VM_ALLOC_NOOBJ implies that the returned page does not have VPO_BUSY set. From
> the comment at the head of both vm_page_alloc() and vm_page_alloc_contig():
>
> * VM_ALLOC_NOOBJ page is not associated with an object and
> * should not have the flag VPO_BUSY set
Ah, oops, forgot about this.
> With regard to the message that the above link points to, I suspect that the
> introduction of vm_page_alloc_contig() can be used to address the first problem
> that you point out. Specifically, one or more OBJT_PHYS vm objects could be
> created and passed to vm_map_find() and then vm_page_alloc_contig() could be
> used to fill these vm objects with memory.
That's exactly what I was trying to do when I encountered a need for
VM_ALLOC_NOOBJ - my object was not NULL.
Alan, BTW, is it safe to map an OBJT_PHYS object into the kernel_map and into a
user map (or a few of them) at the same time?
--
Andriy Gapon
More information about the freebsd-current
mailing list