Re: [RFC Design Doc] Add vNVDIMM support for Xen

[Haozhong Zhang <haozhong.zhang@intel.com>]

On 03/17/16 22:21, Haozhong Zhang wrote:
> On 03/17/16 14:00, Ian Jackson wrote:
> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen"):
> > > QEMU keeps mappings of guest memory because (1) that mapping is
> > > created by itself, and/or (2) certain device emulation needs to access
> > > the guest memory. But for vNVDIMM, I'm going to move the creation of
> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not
> > > access vNVDIMM pages mapped to guest, so it's not necessary to let
> > > qemu keeps vNVDIMM mappings.
> > 
> > I'm confused by this.
> > 
> > Suppose a guest uses an emulated device (or backend) provided by qemu,
> > to do DMA to an vNVDIMM.  Then qemu will need to map the real NVDIMM
> > pages into its own address space, so that it can write to the memory
> > (ie, do the virtual DMA).
> > 
> > That virtual DMA might well involve a direct mapping in the kernel
> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write
> > directly to the NVDIMM, and with luck the actual device backing the
> > virtual device will be able to DMA to the NVDIMM.
> > 
> > All of this seems to me to mean that qemu needs to be able to map
> > its guest's parts of NVDIMMs
> > 
> > There are probably other example: memory inspection systems used by
> > virus scanners etc.; debuggers used to inspect a guest from outside;
> > etc.
> > 
> > I haven't even got started on save/restore...
> > 
> 
> Oops, so many cases I missed. Thanks Ian for pointing out all these!
> Now I need to reconsider how to manage guest permissions for NVDIMM pages.
> 

I still cannot find a neat approach to manage guest permissions for
nvdimm pages. A possible one is to use a per-domain bitmap to track
permissions: each bit corresponding to an nvdimm page. The bitmap can
save lots of spaces and even be stored in the normal ram, but
operating it for a large nvdimm range, especially for a contiguous
one, is slower than rangeset.

BTW, if I take the other way to map nvdimm pages to guest
(http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html)
| 2. Or, given the same inputs, we may combine above two steps into a new
|    dom0 system call that (1) gets the SPA ranges, (2) calls xen
|    hypercall to map SPA ranges
and treat nvdimm as normal ram, then xen will not need to use rangeset
or above bitmap to track guest permissions for nvdimm? But looking at
how qemu currently populates guest memory via XENMEM_populate_physmap
, and other hypercalls like XENMEM_[in|de]crease_reservation, it looks
like that mapping a _dedicated_ piece of host ram to guest is not
allowed out of the hypervisor (and not allowed even in dom0 kernel)?
Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking
guest memory?

Thanks,
Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel