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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.04.16 at 12:16, <haozhong.zhang@intel.com> 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.

Jan


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