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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.03.16 at 14:55, <haozhong.zhang@xxxxxxxxx> 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.

>> 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). 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.

Jan


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