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

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

On 01/20/16 08:58, Andrew Cooper wrote:
> On 20/01/2016 08:46, Jan Beulich wrote:
> >>>> On 20.01.16 at 06:31, <haozhong.zhang@intel.com> wrote:
> >> The primary reason of current solution is to reuse existing NVDIMM
> >> driver in Linux kernel.
> > Re-using code in the Dom0 kernel has benefits and drawbacks, and
> > in any event needs to depend on proper layering to remain in place.
> > A benefit is less code duplication between Xen and Linux; along the
> > same lines a drawback is code duplication between various Dom0
> > OS variants.
> >
> >> One responsibility of this driver is to discover NVDIMM devices and
> >> their parameters (e.g. which portion of an NVDIMM device can be mapped
> >> into the system address space and which address it is mapped to) by
> >> parsing ACPI NFIT tables. Looking at the NFIT spec in Sec 5.2.25 of
> >> ACPI Specification v6 and the actual code in Linux kernel
> >> (drivers/acpi/nfit.*), it's not a trivial task.
> > To answer one of Kevin's questions: The NFIT table doesn't appear
> > to require the ACPI interpreter. They seem more like SRAT and SLIT.
> > Also you failed to answer Kevin's question regarding E820 entries: I
> > think NVDIMM (or at least parts thereof) get represented in E820 (or
> > the EFI memory map), and if that's the case this would be a very
> > strong hint towards management needing to be in the hypervisor.
>

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

But the split does not need to be done at Xen side IMO. It can be done
by dom0 kernel and QEMU as long as they tells Xen hypervisor the
address space range of each part.

Haozhong

> ~Andrew
> 
> >
> >> Secondly, the driver implements a convenient block device interface to
> >> let software access areas where NVDIMM devices are mapped. The
> >> existing vNVDIMM implementation in QEMU uses this interface.
> >>
> >> As Linux NVDIMM driver has already done above, why do we bother to
> >> reimplement them in Xen?
> > See above; a possibility is that we may need a split model (block
> > layer parts on Dom0, "normal memory" parts in the hypervisor.
> > Iirc the split is being determined by firmware, and hence set in
> > stone by the time OS (or hypervisor) boot starts.
> >
> > Jan
> >
>