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

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Roger" == Roger Pau Monne <roger.pau%citrix.com@localhost> writes:

    Roger> 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 ?

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

I think what you mean is mapping "synchronously".

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

I disagree. This is a qemu bug. if qemu updates the pfn/gmfn->mfn
mappings, it should also update its own VA->pfn mappings. The kernel is
doing the right thing here. What we're doing with your patch is to work
around qemu being lame, afaict.

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

uvm(9) shouldn't really be worrying about other domains, that's not its
job.


Cheers,
-- 
Cherry