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

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

On 01/20/16 10:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 20, 2016 at 10:53:10PM +0800, Haozhong Zhang wrote:
> > On 01/20/16 14:45, Andrew Cooper wrote:
> > > 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.
> > >
> > 
> > Yes, those hypercalls are what I'm going to add.
> 
> Why?
> 
> What you need (in a rought hand-wave way) is to:
>  - mount /dev/pmem0
>  - mmap the file on /dev/pmem0 FS
>  - walk the VMA for the file - extract the MFN (machien frame numbers)

Can this step be done by QEMU? Or does linux kernel provide some
approach for the userspace to do the translation?

Haozhong

>  - feed those frame numbers to xc_memory_mapping hypercall. The
>    guest pfns would be contingous.
>    Example: say the E820_NVDIMM starts at 8GB->16GB, so an 8GB file on
>    /dev/pmem0 FS - the guest pfns are 0x200000 upward.
> 
>    However the MFNs may be discontingous as the NVDIMM could be an
>    1TB - and the 8GB file is scattered all over.
> 
> I believe that is all you would need to do?
> > 
> > Haozhong
> > 
> > > >
> > > > 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@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel