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

[Roger Pau Monne <roger.pau%citrix.com@localhost>]

Manuel Bouyer wrote:
> On Tue, Jun 26, 2012 at 10:47:05AM +0100, Roger Pau Monne wrote:
> > > informations. I think qemu should instruct the kernel that
> > > things changed.
> > With the proposed patch, the kernel doesn't store the gfns anymore,
> > since the mapping is done directly, and no pagefault handler is set.
> > So the information (or the lack of it) stored by the NetBSD kernel
> > is correct.
>
> OK. As this is a mapping which isn't consuming dom0 memory I guess it
> doesn't matter much that this area is not paged. But I think PRIVCMD_MMAP
> and PRIVCMD_MMAPBATCH should behave the same. I don't like much the idea
> of a mapping in user area that is unknown to UVM though, can't you make
> qemu unmap and remap the area with the right information ?

Yes, I agree, I will resubmit a patch that changes both 
PRIVCMD_MMAPBATCH and PRIVCMD_MMAP to direct mapping.

I could try to upstream a patch to Qemu, but this kind of behaviour 
(moving gfns) is allowed by the Xen Hypervisor (they should only be 
valid gfns during the xc_map_foreign*, after that there's no guarantee) 
so I think the NetBSD kernel should be prepared to handle this 
correctly, instead of trying to fix the upstream tools that make use of it.

I don't think there's any easy way of adding this to UVM with the right 
gfns, unless we keep track of hypercalls like xc_domain_add_to_physmap 
and update the gfns of the associated privcmd_object struct.