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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 04/22/16 04:53, Jan Beulich wrote:
> >>> On 22.04.16 at 12:16, <haozhong.zhang@xxxxxxxxx> wrote:
> > On 04/22/16 02:24, Jan Beulich wrote:
> > [..]
> >> >> >> Well, using existing range struct to manage guest access permissions
> >> >> >> to nvdimm could consume too much space which could not fit in either
> >> >> >> memory or nvdimm. If the above solution looks really error-prone,
> >> >> >> perhaps we can still come back to the existing one and restrict the
> >> >> >> number of range structs each domain could have for nvdimm
> >> >> >> (e.g. reserve one 4K-page per-domain for them) to make it work for
> >> >> >> nvdimm, though it may reject nvdimm mapping that is terribly
> >> >> >> fragmented.
> >> >> > 
> >> >> > Hi Jan,
> >> >> > 
> >> >> > Any comments for this?
> >> >> 
> >> >> Well, nothing new, i.e. my previous opinion on the old proposal didn't
> >> >> change. I'm really opposed to any artificial limitations here, as I am 
> >> >> to
> >> >> any secondary (and hence error prone) code paths. IOW I continue
> >> >> to think that there's no reasonable alternative to re-using the existing
> >> >> memory management infrastructure for at least the PMEM case.
> >> > 
> >> > By re-using the existing memory management infrastructure, do you mean
> >> > re-using the existing model of MMIO for passthrough PCI devices to
> >> > handle the permission of pmem?
> >> 
> >> No, re-using struct page_info.
> >> 
> >> >> The
> >> >> only open question remains to be where to place the control structures,
> >> >> and I think the thresholding proposal of yours was quite sensible.
> >> > 
> >> > I'm little confused here. Is 'restrict the number of range structs' in
> >> > my previous reply the 'thresholding proposal' you mean? Or it's one of
> >> > 'artificial limitations'?
> >> 
> >> Neither. It's the decision on where to place the struct page_info
> >> arrays needed to manage the PMEM ranges.
> >>
> > 
> > In [1][2], we have agreed to use struct page_info to manage mappings
> > for pmem and place them in reserved area on pmem.
> > 
> > But I think the discussion in this thread is to decide the data
> > structure which will be used to track access permission to host pmem.
> > The discussion started from my question in [3]:
> > | I'm not sure whether xen toolstack as a userspace program is
> > | considered to be safe to pass the host physical address (of host
> > | NVDIMM) to hypervisor.
> > In reply [4], you mentioned:
> > | As long as the passing of physical addresses follows to model of
> > | MMIO for passed through PCI devices, I don't think there's problem
> > | with the tool stack bypassing the Dom0 kernel. So it really all
> > | depends on how you make sure that the guest won't get to see memory
> > | it has no permission to access.
> > 
> > I interpreted it as the same access permission control mechanism used
> > for MMIO of passthrough pci devices (built around range struct) should
> > be used for pmem as well, so that we can safely allow toolstack to
> > pass the host physical address of nvdimm to hypervisor.
> > Was my understanding wrong from the beginning?
> 
> Perhaps I have got confused by the back and forth. If we're to
> use struct page_info, then everything should be following a
> similar flow to what happens for normal RAM, i.e. normal page
> allocation, and normal assignment of pages to guests.
>

I'll follow the normal assignment of pages to guests for pmem, but not
the normal page allocation. Because allocation is difficult to always
get the same pmem area for the same guest every time. It still needs
input from others (e.g. toolstack) that can provide the exact address.

Because the address is now not decided by xen hypervisor, certain
permission track is needed. For this part, we will re-use the existing
one for MMIO. Directly using existing range struct for pmem may
consume too much space, so I proposed to choose different data
structures or put limitation on exiting range struct to avoid or
mitigate this problem. The data structure change will be applied only
to pmem, and only the code that manipulate the range structs
(rangeset_*) will be changed for pmem. So for the permission tracking
part, it will still follow the exiting one.

Haozhong


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