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

[Haozhong Zhang <haozhong.zhang@intel.com>]

On 03/16/16 08:23, Jan Beulich wrote:
> >>> On 16.03.16 at 14:55, <haozhong.zhang@intel.com> wrote:
> > On 03/16/16 07:16, Jan Beulich wrote:
> >> Which reminds me: When considering a file on NVDIMM, how
> >> are you making sure the mapping of the file to disk (i.e.
> >> memory) blocks doesn't change while the guest has access
> >> to it, e.g. due to some defragmentation going on?
> > 
> > The current linux kernel 4.5 has an experimental "raw device dax
> > support" (enabled by removing "depends on BROKEN" from "config
> > BLK_DEV_DAX") which can guarantee the consistent mapping. The driver
> > developers are going to make it non-broken in linux kernel 4.6.
> 
> But there you talk about full devices, whereas my question was
> for files.
>

the raw device dax support is for files on NVDIMM.

> >> And
> >> talking of fragmentation - how do you mean to track guest
> >> permissions for an unbounded number of address ranges?
> >>
> > 
> > In this case range structs in iomem_caps for NVDIMMs may consume a lot
> > of memory, so I think they are another candidate that should be put in
> > the reserved area on NVDIMM. If we only allow to grant access
> > permissions to NVDIMM page by page (rather than byte), the number of
> > range structs for each NVDIMM in the worst case is still decidable.
> 
> Of course the permission granularity is going to by pages, not
> bytes (or else we couldn't allow the pages to be mapped into
> guest address space). And the limit on the per-domain range
> sets isn't going to be allowed to be bumped significantly, at
> least not for any of the existing ones (or else you'd have to
> prove such bumping can't be abused).

What is that limit? the total number of range structs in per-domain
range sets? I must miss something when looking through 'case
XEN_DOMCTL_iomem_permission' of do_domctl() and didn't find that
limit, unless it means alloc_range() will fail when there are lots of
range structs.

> Putting such control
> structures on NVDIMM is a nice idea, but following our isolation
> model for normal memory, any such memory used by Xen
> would then need to be (made) inaccessible to Dom0.
>

I'm not clear how this is done. By marking those inaccessible pages as
unpresent in dom0's page table? Or any example I can follow?

Thanks,
Haozhong

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