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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Jan 20, 2016 at 11:29:55PM +0800, Xiao Guangrong wrote:
> 
> 
> On 01/20/2016 07:20 PM, Jan Beulich wrote:
> >>>>On 20.01.16 at 12:04, <haozhong.zhang@xxxxxxxxx> wrote:
> >>On 01/20/16 01:46, Jan Beulich wrote:
> >>>>>>On 20.01.16 at 06:31, <haozhong.zhang@xxxxxxxxx> wrote:
> >>>>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.
> >
> >To answer this I need to have my understanding of the partitioning
> >being done by firmware confirmed: If that's the case, then "normal"
> >means the part that doesn't get exposed as a block device (SSD).
> >In any event there's no correlation to guest exposure here.
> 
> Firmware does not manage NVDIMM. All the operations of nvdimm are handled
> by OS.
> 
> Actually, there are lots of things we should take into account if we move
> the NVDIMM management to hypervisor:

If you remove the block device part and just deal with pmem part then this
gets smaller.

Also the _DSM operations - I can't see them being in hypervisor - but only
in the dom0 - which would have the right software to tickle the correct
ioctl on /dev/pmem to do the "management" (carve the NVDIMM, perform
an SMART operation, etc).

> a) ACPI NFIT interpretation
>    A new ACPI table introduced in ACPI 6.0 is named NFIT which exports the
>    base information of NVDIMM devices which includes PMEM info, PBLK
>    info, nvdimm device interleave, vendor info, etc. Let me explain it one
>    by one.

And it is a static table. As in part of the MADT.
> 
>    PMEM and PBLK are two modes to access NVDIMM devices:
>    1) PMEM can be treated as NV-RAM which is directly mapped to CPU's address
>       space so that CPU can r/w it directly.
>    2) as NVDIMM has huge capability and CPU's address space is limited, NVDIMM
>       only offers two windows which are mapped to CPU's address space, the 
> data
>       window and access window, so that CPU can use these two windows to 
> access
>       the whole NVDIMM device.
> 
>    NVDIMM device is interleaved whose info is also exported so that we can
>    calculate the address to access the specified NVDIMM device.

Right, along with the serial numbers.
> 
>    NVDIMM devices from different vendor can have different function so that 
> the
>    vendor info is exported by NFIT to make vendor's driver work.

via _DSM right?
> 
> b) ACPI SSDT interpretation
>    SSDT offers _DSM method which controls NVDIMM device, such as label 
> operation,
>    health check etc and hotplug support.

Sounds like the control domain (dom0) would be in charge of that.
> 
> c) Resource management
>    NVDIMM resource management challenged as:
>    1) PMEM is huge and it is little slower access than RAM so it is not 
> suitable
>       to manage it as page struct (i think it is not a big problem in Xen
>       hypervisor?)
>    2) need to partition it to it be used in multiple VMs.
>    3) need to support PBLK and partition it in the future.

That all sounds to me like an control domain (dom0) decisions. Not Xen 
hypervisor.
> 
> d) management tools support
>    S.M.A.R.T? error detection and recovering?
> 
> c) hotplug support

How does that work? Ah the _DSM will point to the new ACPI NFIT for the OS
to scan. That would require the hypervisor also reading this for it to
update it's data-structures.
> 
> d) third parts drivers
>    Vendor drivers need to be ported to xen hypervisor and let it be supported 
> in
>    the management tool.

Ewww.

I presume the 'third party drivers' mean more interesting _DSM features right?
On the base level the firmware with this type of NVDIMM would still have
the basic - ACPI NFIT + E820_NVDIMM (optional).
> 
> e) ...
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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