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

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

On 01/20/16 01: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.
>

CC'ing QEMU vNVDIMM maintainer: Xiao Guangrong

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

Not clear about other Dom0 OS. But for Linux, it already has a NVDIMM
driver since 4.2.

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

Sorry, I made a mistake in another reply. NFIT does not contain
anything requiring ACPI interpreter. But there are some _DSM methods
for NVDIMM in SSDT, which needs ACPI interpreter.

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

Legacy NVDIMM devices may use E820 entries or other ad-hoc ways to
announce their locations, but newer ones that follow ACPI v6 spec do
not need E820 any more and only need ACPI NFIT (i.e. firmware may not
build E820 entries for them).

The current linux kernel can handle both legacy and new NVDIMM devices
and provide the same block device interface for them.

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

For the "normal memory" parts, do you mean parts that map the host
NVDIMM device's address space range to the guest? I'm going to
implement that part in hypervisor and expose it as a hypercall so that
it can be used by QEMU.

Haozhong