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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> 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.

Jan


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