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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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.

> > +#ifdef ENABLE_ROMBIOS
> > +            else if ( bios == &rombios_config )
> > +            {
> > +                bios->acpi_build_tables(0, 0);
> > +            }
> > +#endif
> > +            else
> > +            {
> > +                printf("no ACPI DSDT image found\n");
> > +                BUG();
> > +            }
> 
> Is this really fatal? It's not like "no ACPI" == "end of the world",
> is it?

I guest it's not fatal, I'll give it a try and just print a warning.

-- 
Anthony PERARD

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