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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.03.16 at 09:58, <haozhong.zhang@xxxxxxxxx> wrote:
> On 03/16/16 09:23, Jan Beulich wrote:
>> >>> On 16.03.16 at 15:55, <haozhong.zhang@xxxxxxxxx> wrote:
>> > On 03/16/16 08:23, Jan Beulich wrote:
>> >> >>> On 16.03.16 at 14:55, <haozhong.zhang@xxxxxxxxx> wrote:
>> >> > On 03/16/16 07:16, Jan Beulich wrote:
>> >> >> 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.
>> 
>> Oh, I'm sorry, that was a different set of range sets I was
>> thinking about. But note that excessive creation of ranges
>> through XEN_DOMCTL_iomem_permission is not a security issue
>> just because of XSA-77, i.e. we'd still not knowingly allow a
>> severe increase here.
>>
> 
> I didn't notice that multiple domains can all have access permission
> to an iomem range, i.e. there can be multiple range structs for a
> single iomem range. If range structs for NVDIMM are put on NVDIMM,
> then there would be still a huge amount of them on NVDIMM in the worst
> case (maximum number of domains * number of NVDIMM pages).
> 
> A workaround is to only allow a range of NVDIMM pages be accessed by a
> single domain. Whenever we add the access permission of NVDIMM pages
> to a domain, we also remove the permission from its current
> grantee. In this way, we only need to put 'number of NVDIMM pages'
> range structs on NVDIMM in the worst case.

But will this work? There's a reason multiple domains are permitted
access: The domain running qemu for the guest, for example,
needs to be able to access guest memory.

No matter how much you and others are opposed to this, I can't
help myself thinking that PMEM regions should be treated like RAM
(and hence be under full control of Xen), whereas PBLK regions
could indeed be treated like MMIO (and hence partly be under the
control of Dom0).

Jan


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