Date: Mon, 05 Dec 2011 18:08:11 -0600
From: Alan Cox <alc@rice.edu>
To: Andriy Gapon <avg@FreeBSD.org>
Cc: Alan Cox <alc@FreeBSD.org>, freebsd-emulation@FreeBSD.org, FreeBSD current <freebsd-current@FreeBSD.org>
Subject: Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
Message-ID: <4EDD5CEB.1020502@rice.edu>
In-Reply-To: <4EDD47D3.5010803@FreeBSD.org>
References: <4ECF7440.4070300@entel.upc.edu> <20111126163343.GA9150@reks> "<4ED6AEFE.4010106@FreeBSD.org>" <201111301807.21351.jkim@FreeBSD.org> <60ea779052f025798cf65e18c24b7b31@bluelife.at> <47eb9f9b139dd8c59b050f1670a5f18d@bluelife.at> <7c3c9505867f4528af276a571077b9ce@bluelife.at> <4EDCC1C6.3040109@FreeBSD.org> <ce531a25e601ca82701d259808d7d485@bluelife.at> <4EDCCDA2.5070006@FreeBSD.org> <4EDD0644.5030902@rice.edu> <4EDD3F60.8050601@FreeBSD.org> <4EDD442C.9030406@rice.edu> <4EDD47D3.5010803@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EDD5CEB.1020502>