Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/01/16 14:29, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>> On 20/01/16 10:36, Xiao Guangrong wrote:
>>> Hi,
>>>
>>> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
>>>
>>>> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
>>>>
>>>>> Conceptually, an NVDIMM is just like a fast SSD which is linearly
>>>>> mapped
>>>>> into memory.  I am still on the dom0 side of this fence.
>>>>>
>>>>> The real question is whether it is possible to take an NVDIMM, split it
>>>>> in half, give each half to two different guests (with appropriate NFIT
>>>>> tables) and that be sufficient for the guests to just work.
>>>>>
>>>> Yes, one NVDIMM device can be split into multiple parts and assigned
>>>> to different guests, and QEMU is responsible to maintain virtual NFIT
>>>> tables for each part.
>>>>
>>>>> Either way, it needs to be a toolstack policy decision as to how to
>>>>> split the resource.
>>> Currently, we are using NVDIMM as a block device and a DAX-based
>>> filesystem
>>> is created upon it in Linux so that file-related accesses directly reach
>>> the NVDIMM device.
>>>
>>> In KVM, If the NVDIMM device need to be shared by different VMs, we can
>>> create multiple files on the DAX-based filesystem and assign the file to
>>> each VMs. In the future, we can enable namespace (partition-like) for
>>> PMEM
>>> memory and assign the namespace to each VMs (current Linux driver uses
>>> the
>>> whole PMEM as a single namespace).
>>>
>>> I think it is not a easy work to let Xen hypervisor recognize NVDIMM
>>> device
>>> and manager NVDIMM resource.
>>>
>>> Thanks!
>>>
>> The more I see about this, the more sure I am that we want to keep it as
>> a block device managed by dom0.
>>
>> In the case of the DAX-based filesystem, I presume files are not
>> necessarily contiguous.  I also presume that this is worked around by
>> permuting the mapping of the virtual NVDIMM such that the it appears as
>> a contiguous block of addresses to the guest?
>>
>> Today in Xen, Qemu already has the ability to create mappings in the
>> guest's address space, e.g. to map PCI device BARs.  I don't see a
>> conceptual difference here, although the security/permission model
>> certainly is more complicated.
> I imagine that mmap'ing  these /dev/pmemXX devices require root
> privileges, does it not?

I presume it does, although mmap()ing a file on a DAX filesystem will
work in the standard POSIX way.

Neither of these are sufficient however.  That gets Qemu a mapping of
the NVDIMM, not the guest.  Something, one way or another, has to turn
this into appropriate add-to-phymap hypercalls.

>
> I wouldn't encourage the introduction of anything else that requires
> root privileges in QEMU. With QEMU running as non-root by default in
> 4.7, the feature will not be available unless users explicitly ask to
> run QEMU as root (which they shouldn't really).

This isn't how design works.

First, design a feature in an architecturally correct way, and then
design an security policy to fit.  (note, both before implement happens).

We should not stunt design based on an existing implementation.  In
particular, if design shows that being a root only feature is the only
sane way of doing this, it should be a root only feature.  (I hope this
is not the case, but it shouldn't cloud the judgement of a design).

~Andrew

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