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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 03/29/16 03:11, Jan Beulich wrote:
> >>> On 29.03.16 at 10:47, <haozhong.zhang@xxxxxxxxx> wrote:
> > 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.
> 
> I don't follow: What would a single bit in that bitmap mean? Any
> guest may access the page? That surely wouldn't be what we
> need.
>

For a host having a N pages of nvdimm, each domain will have a N bits
bitmap. If the m'th bit of a domain's bitmap is set, then that domain
has the permission to access the m'th host nvdimm page.

> > 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?
> 
> Well, it's simply because RAM is a resource managed through
> allocation/freeing, instead of via reserving chunks for special
> purposes.
> 

So that means xen can always ensure the ram assigned to a guest is
what the guest is permitted to access, so no data structures like
iomem_caps is needed for ram. If I have to introduce a hypercall that
maps the dedicated host ram/nvdimm to guest, then the explicit
permission management is still needed, regardless of who (dom0 kernel,
qemu or toolstack) will use it. Right?

Haozhong

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