[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


[1] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01161.html
[2] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01201.html
[3] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html
[4] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01981.html

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.