Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}

From: Alan Cox <alc_at_rice.edu>
Date: Mon, 05 Dec 2011 18:08:11 -0600
On 12/5/2011 4:38 PM, Andriy Gapon wrote:
> on 06/12/2011 00:22 Alan Cox said the following:
>> On 12/5/2011 4:02 PM, Andriy Gapon wrote:
>>> 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?
>>>
>> Yes, it is.
> Thank you!  And another question - what would you recommend as a substitute for
> vm_page_alloc_contig in FreeBSD versions that do not have it?  All I can think
> of is essentially replicating kmem_alloc_contig + contigmapping and allowing a
> user-specified object to be used in place of kernel_object.
>

The right thing to do is to MFC vm_page_alloc_contig().  It shouldn't be 
that hard to merge it.

Alan
Received on Mon Dec 05 2011 - 23:08:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:21 UTC