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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.03.16 at 12:10, <haozhong.zhang@xxxxxxxxx> wrote:
> 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.

Which will be more overhead as soon as there are enough such
domains in a system.

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

Yes (if you really mean to go that route).

Jan

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