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

On 12/05/2011 07:56, Andriy Gapon wrote:
> on 05/12/2011 15:15 Bernhard Froehlich said the following:
>> On 05.12.2011 14:06, Andriy Gapon wrote:
>>> on 05/12/2011 14:57 Bernhard Froehlich said the following:
>>>> On 02.12.2011 12:55, Bernhard Froehlich wrote:
>>>>> Patch has been send upstream:
>>>>>
>>>>>
>>>>>
>>>>> https://www.virtualbox.org/pipermail/vbox-dev/2011-December/004842.html
>>>> Patches have been committed upstream. Thanks a lot guys!
>>>>
>>>> https://www.virtualbox.org/changeset/39521
>>>>
>>> BTW, I think that we additionally need VM_ALLOC_NOBUSY in flags that
>>> we pass to vm_phys_alloc_contig.
>> What's the difference of this?
> 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

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.

Alan