Re: [RFC Design Doc] Add vNVDIMM support for Xen

From: Ross Philipson <ross.philipson@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Haozhong Zhang <haozhong.zhang@intel.com>
Cc: Juergen Gross <JGross@suse.com>,
	Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, Jun Nakajima <jun.nakajima@intel.com>,
	Xiao Guangrong <guangrong.xiao@linux.intel.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen
Date: Fri, 5 Feb 2016 09:40:34 -0500	[thread overview]
Message-ID: <56B4B462.1090005@gmail.com> (raw)
In-Reply-To: <56B20A10.70603@citrix.com>

On 02/03/2016 09:09 AM, Andrew Cooper wrote:
> On 03/02/16 09:13, Jan Beulich wrote:
>>>>> On 03.02.16 at 08:00, <haozhong.zhang@intel.com> wrote:
>>> On 02/02/16 17:11, Stefano Stabellini wrote:
>>>> Once upon a time somebody made the decision that ACPI tables
>>>> on Xen should be static and included in hvmloader. That might have been
>>>> a bad decision but at least it was coherent. Loading only *some* tables
>>>> from QEMU, but not others, it feels like an incomplete design to me.
>>>>
>>>> For example, QEMU is currently in charge of emulating the PCI bus, why
>>>> shouldn't it be QEMU that generates the PRT and MCFG?
>>>>
>>> To Keir, Jan and Andrew:
>>>
>>> Are there anything related to ACPI that must be done (or are better to
>>> be done) in hvmloader?
>> Some of the static tables (FADT and HPET come to mind) likely would
>> better continue to live in hvmloader. MCFG (for example) coming from
>> qemu, otoh, would be quite natural (and would finally allow MMCFG
>> support for guests in the first place). I.e. ...
>>
>>>> I prefer switching to QEMU building all ACPI tables for devices that it
>>>> is emulating. However this alternative is good too because it is
>>>> coherent with the current design.
>>> I would prefer to this one if the final conclusion is that only one
>>> agent should be allowed to build guest ACPI. As I said above, it looks
>>> like a big change to switch to QEMU for all ACPI tables and I'm afraid
>>> it would break some existing guests.
>> ... I indeed think that tables should come from qemu for components
>> living in qemu, and from hvmloader for components coming from Xen.
>
> I agree.
>
> There has to be a single entity responsible for collating the eventual
> ACPI handed to the guest, and this is definitely HVMLoader.
>
> However, it is correct that Qemu create the ACPI tables for the devices
> it emulates for the guest.
>
> We need to agree on a mechanism whereby each entity can provide their
> own subset of the ACPI tables to HVMLoader, and have HVMLoader present
> the final set properly to the VM.
>
> There is an existing usecase of passing the Host SLIC table to a VM, for
> OEM Versions of Windows.  I believe this is achieved with
> HVM_XS_ACPI_PT_{ADDRESS,LENGTH}, but that mechanism is a little
> inflexible and could probably do with being made a little more generic.

A while back I added a generic mechanism to load extra ACPI tables into 
a guest, configurable at runtime. It looks like the functionality is 
still present. That might be an option.

Also, following the thread, it wasn't clear if some of the tables like 
the SSDT for the NVDIMM device and it's _FIT/_DSM methods were something 
that could be statically created at build time. If it is something that 
needs to be generated at runtime (e.g. platform specific), I have a 
library that can generate any AML on the fly and create SSDTs.

Anyway just FYI in case this is helpful.

>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

-- 
Ross Philipson