Allocating physical memory without a kernel mapping

[Alexander Eichner]

Giovanni Trematerra wrote:
> On Mon, Mar 1, 2010 at 10:59 AM, Alexander Eichner <alexeichi at yahoo.de> wrote:
> > Hi,
> >
> > I'm currently trying to finish the R0 memory implementation[1] of FreeBSD for VirtualBox. One of the missing methods allocates physical non contiguous pages which don't need to have a kernel mapping (rtR0MemObjNativeAllocPhysNC). I'm using vm_phys_alloc_contig to achieve this. The pages are than mapped into the user space VM process using pmap_enter (rtR0MemObjNativeMapUser) and if they are not needed anymore vm_page_free_toq is used to free the pages (rtR0MemObjNativeFree).
> > Everything works as long as the VM runs but if the VM process terminates and I do something else the host will panic at some point (usually when I try to start a gnome session) with "pmap_enter: missing reference to page table page <va>"[2].
> > There seems to some problem with the wire count of that page but I can't see what I'm doing wrong at the moment.
> > Thanks in advance for any help.
> 
> Please, try this patch against revision 26898.
> 
> --- memobj-r0drv-freebsd.c.orig 2010-02-26 10:28:44.000000000 +0100
> +++ memobj-r0drv-freebsd.c      2010-02-26 13:55:35.000000000 +0100
> @@ -209,8 +209,7 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
>                 vm_page_t   pPage;
> 
>                 pPage = vm_page_alloc(pMemFreeBSD->pObject, PageIndex,
> -                                      VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM |
> -                                      VM_ALLOC_WIRED);
> +                                      VM_ALLOC_NOBUSY | VM_ALLOC_SYSTEM);
> 
>  #if __FreeBSD_version >= 800000 /** @todo Find exact version number */
>                 /* Fixes crashes during VM termination on
> FreeBSD8-CURRENT amd64
> @@ -220,9 +219,6 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
> 
>                 if (pPage)
>                 {
> -                    vm_page_lock_queues();
> -                    vm_page_wire(pPage);
> -                    vm_page_unlock_queues();
>                     /* Put the page into the page table now. */
>  #if __FreeBSD_version >= 701105
>                     pmap_enter(kernel_map->pmap, AddressDst,
> VM_PROT_NONE, pPage,
> @@ -253,6 +249,8 @@ int rtR0MemObjNativeAllocPage(PPRTR0MEMO
> 
>             if (rc == VINF_SUCCESS)
>             {
> +                               vm_map_wire(kernel_map, MapAddress,
> MapAddress + cb,
> +                                               VM_MAP_WIRE_SYSTEM |
> VM_MAP_WIRE_NOHOLES);
>                 pMemFreeBSD->Core.pv = (void *)MapAddress;
>                 *ppMem = &pMemFreeBSD->Core;
>                 return VINF_SUCCESS;
> 
> >
> > Regards,
> > Alexander Eichner
> >
> > [1] http://www.virtualbox.org/browser/trunk/src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c?rev=26899
> > [2]http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c?im=bigexcerpts#L3076
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
> > http://mail.yahoo.com
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> >
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

Thanks for your help but I don't see how that patch could help with my
problem. rtR0MemObjNativeAllocPage allocates pages with a kernel
mapping but the problem appears when using rtR0MemObjNativeAllocPhysNC
+ rtR0MemObjNativeMapUser and freeing the pages later.
rtR0MemObjNativeAllocPage is used if I use the old allocation mode which
does not use rtR0MemObjNativeAllocPhysNC and this works fine here.
The double wiring problem should also be solved with the latest source.

Regards,
Alexander