Re: [Xen-devel] [PATCH v3 13/16] hvmloader: Load ACPI tables from hvm_start_info module

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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)?

Jan


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