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

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: 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: Wed, 3 Feb 2016 14:09:20 +0000	[thread overview]
Message-ID: <56B20A10.70603@citrix.com> (raw)
In-Reply-To: <56B1D2CB02000078000CDD82@prv-mh.provo.novell.com>

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.

~Andrew