Re: [PATCH v2] port/xen: map memory directly in privcmd PRIVCMD_MMAPBATCH

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jun 26, 2012 at 10:18:59AM +0100, Roger Pau Monne wrote:
> >OK, so if I understand it properly
> >- qemu maps pages that will be 0x3f800 in guest's physical space.
> 
> Yes, this is supposedly going to be the video region of the guest.
> 
> >   Let says it's mapped at BASE+0x3f800 in qemu's virtual space
> >   (I assume qemu actually uses a linear mapping of the guest's physical
> >   space).
> >- later something (the hypervisor ?) moves this page to 0xf0000 in
> >   guest's physical space. In which way ? does it remap the underlying mfn
> >   to a different pfn ?
> 
> Then, when Qemu starts, the guests writes the BAR, and Qemu detects
> that the guest wants the video ram at address 0xf0000, since this is
> different from the previous address (0x3f800), Qemu calls
> xc_domain_add_to_physmap(..., idx=0x3f800, gpfn=0xf0000), thus
> moving that gfns in the guest p2m.
> 
> With current NetBSD implementation, we didn't notice this change,
> and the NetBSD kernel still thinks this pages in Qemu address space
> are mapped to 0x3f800, so when Qemu tries to write to this pages in
> it's address space, NetBSD kernel hits the pagefault and we try to
> map 0x3f800, getting an error from the hypervisor, because this gfn
> (0x3f800) is no longer accessible, we should instead try to map the
> new one (0xf0000).
> 
> >- In qemu's virtual space the underlying pages are still mapped at
> >   BASE+0x3f800, when it should now be BASE+0xf0000. How does the
> >   proposed patch help there ? making the mapping wired won't make
> >   it move automatically, unless there's some magic happening.
> 
> Since this are gfns, they are not "real" addresses, they are just in
> the p2m guest table handled by the hypervisor. The underlying
> machine addresses don't change, the only thing that changes are the
> gfns that Xen assigns to them. So if NetBSD kernel maps the memory
> directly in the call to xc_map_foreign_bulk, we don't care that the
> gfns change, since the machine addresses behind those gfn are going
> to be the same, and we will already have them mapped in Qemu address
> space correctly.

But this still looks bogus to me. We let the kernel live with wrong
informations. I think qemu should instruct the kernel that
things changed.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--