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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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