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

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

Cherry G.Mathew wrote:
> > > > > > "Roger" == Roger Pau Monne<roger.pau%citrix.com@localhost>  writes:
 > I'm still missing something here, but I think something is not right
> here. I *think* qemu or NetBSD is mixing up the guest's gmfns (pfns) and
> dom0 mfns here.
>
> - qemu queries the hypervisor for the guest pfn (aka gmfn) via: [1]
>     xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN,&ioreq_pfn);

With this call we get a set of gfns of the guest.

> - It then maps it into the dom0 qemu pmap via: [2]
>   state->shared_page = xc_map_foreign_range(xen_xc, xen_domid,
>     XC_PAGE_SIZE, PROT_READ|PROT_WRITE, ioreq_pfn);

Then we map those gfn pages to the virtual address space of Qemu.

> Note that NetBSD is assuming that ioreq_pfn is a dom0 mfn at this point!

NetBSD only has it's own p2m table. This is just mapping a region of the 
guest memory to the Qemu address space, but all the mappings are done by 
the hypervisor, since the mfns of the guest are not part of the mfns of 
the NetBSD kernel (dom0).

> At this point, as if by magic, the dom0 mfns point to the correct
> hvm ioreq_pfns. I'm guessing this is because the dom0 p2m table is
> identity mapped ? hmmmmmmmmmmmmmmmm....... not good!

No, this is outside of the NetBSD p2m table. We don't have the guest p2m 
table, we only have a common memory region mapped to both domains (guest 
and dom0), but this underlying mfns are not part of the dom0 mfns, they 
are handled by the hypervisor.

> - next qemu updates the *guest* p2m by calling: [3]
>    rc = xc_domain_add_to_physmap(xen_xc, xen_domid, XENMAPSPACE_gmfn,
>    idx, gpfn);
>
> I'm not sure how this mapping is working at all. I think NetBSD's
> privcmd.c needs to be updating its own p2m during the foreign domain
> page mappings by considering them to be gmfns (ie; guest pfns).

I don't think so, the NetBSD p2m table is related to the NetBSD kernel 
only (dom0), it doesn't contain entries from other domains, and this 
mappings are not using dom0 memory.

> My terminology of page/machine frames is from:
> http://xenbits.xen.org/hg/xen-unstable.hg/file/cd4dd23a831d/xen/include/asm-x86/mm.h#l431
>
> Cheers,