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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 02/03/16 14:09, 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.
>

Yes, that is what one of my v1 patches does
([PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu).

It extends the existing construct_passthrough_tables() to get the
address and size of acpi tables from its parameters (a pair of
xenstore keys) rather than the hardcoded ones.

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