[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 13/16] hvmloader: Load ACPI tables from hvm_start_info module
On Fri, Mar 04, 2016 at 01:39:38AM -0700, Jan Beulich wrote: > >>> On 03.03.16 at 18:59, <anthony.perard@xxxxxxxxxx> wrote: > > On Tue, Mar 01, 2016 at 09:17:25AM -0700, Jan Beulich wrote: > >> >>> On 25.02.16 at 15:56, <anthony.perard@xxxxxxxxxx> 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)? I have not though about using the same one for both. I could try to change the tables we have to make it work with both. But that for another time. Thanks, -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |