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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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

Ian.

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