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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 01/15/16 10:10, Jan Beulich wrote:
> >>> On 29.12.15 at 12:31, <haozhong.zhang@xxxxxxxxx> wrote:
> > NVDIMM devices are detected and configured by software through
> > ACPI. Currently, QEMU maintains ACPI tables of vNVDIMM devices. This
> > patch extends the existing mechanism in hvmloader of loading passthrough
> > ACPI tables to load extra ACPI tables built by QEMU.
> 
> Mechanically the patch looks okay, but whether it's actually needed
> depends on whether indeed we want NV RAM managed in qemu
> instead of in the hypervisor (where imo it belongs); I didn' see any
> reply yet to that same comment of mine made (iirc) in the context
> of another patch.
> 
> Jan
> 

One purpose of this patch series is to provide vNVDIMM backed by host
NVDIMM devices. It requires some drivers to detect and manage host
NVDIMM devices (including parsing ACPI, managing labels, etc.) that
are not trivial, so I leave this work to the dom0 linux. Current Linux
kernel abstract NVDIMM devices as block devices (/dev/pmemXX). QEMU
then mmaps them into certain range of dom0's address space and asks
Xen hypervisor to map that range of address space to a domU.

However, there are two problems in this Xen patch series and the
corresponding QEMU patch series, which may require further
changes in hypervisor and/or toolstack.

(1) The QEMU patches use xc_hvm_map_io_range_to_ioreq_server() to map
    the host NVDIMM to domU, which results VMEXIT for every guest
    read/write to the corresponding vNVDIMM devices. I'm going to find
    a way to passthrough the address space range of host NVDIMM to a
    guest domU (similarly to what xen-pt in QEMU uses)
    
(2) Xen currently does not check whether the address that QEMU asks to
    map to domU is really within the host NVDIMM address
    space. Therefore, Xen hypervisor needs a way to decide the host
    NVDIMM address space which can be done by parsing ACPI NFIT
    tables.

Haozhong

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