>>> On 03.03.16 at 18:59, <anthony.per...@citrix.com> wrote: > On Tue, Mar 01, 2016 at 09:17:25AM -0700, Jan Beulich wrote: >> >>> On 25.02.16 at 15:56, <anthony.per...@citrix.com> wrote: >> > --- a/tools/firmware/hvmloader/hvmloader.c >> > +++ b/tools/firmware/hvmloader/hvmloader.c >> > @@ -365,8 +365,26 @@ int main(void) >> > >> > if ( bios->acpi_build_tables ) >> > { >> > + const struct hvm_modlist_entry *acpi_module; >> > + acpi_module = get_module_entry(hvm_start_info, "acpi"); >> > printf("Loading ACPI ...\n"); >> > - bios->acpi_build_tables(); >> > + if ( acpi_module ) >> > + { >> > + uint32_t paddr = acpi_module->paddr; >> > + bios->acpi_build_tables((void*)paddr, >> > + acpi_module->size); >> > + } >> >> Hmm, so far it was the build process which ensured the right ACPI >> tables would be used with the corresponding BIOS. The disconnect >> that gets introduced here worries me a little, since things having >> got out of sync may be rather hard to diagnose (as they may >> surface only much later). > > So, my ultimate goal with this series was to be able to create a guest with > QEMU's Q35 machine, which would need a different ACPI tables. > > Also, I would say that the ACPI tables are already disconnected from the > thing they describe, the device model QEMU. I don't think there is much > information about the BIOS backed into the DSDT table.
But then why would the Q35 model need a different one? Or the other way around, why wouldn't that other one be usable with with the current machine type (or more generally, why couldn't we have one that fits all machine types we mean to support)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel