[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel



--
Ross Philipson

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.