[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Wed, 29 May 2013 11:42:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6


>>> possible complexity of having to regenerate
>>> tables on a vm reboot,
>> Why tables should be regenerated at reboot?  I remember hotplug being
>> mentioned in the call.  Hmm?  Which hotplugged component needs acpi
>> table updates to work properly?  And what is the point of hotplugging if
>> you must reboot the guest anyway to get the acpi updates needed?
>> Details please.
> I think it's a mistake. I sent a mail explaining this part.

Saw it meanwhile.

>> Also mentioned in the call: "architectural reasons", which I understand
>> as "real hardware works that way".  Correct.
> Not exactly. Real hardware is very likely to have
> most of the tables pre-generated in ROM, load
> them and tweak them in the minor way.

>From a quick look it seems coreboot has a static (iasl-compiled) dsdt
and generates everything else.


>> Agree on this one.  Ideally the acpi table generation code should be
>> able to gather all information it needs from the qom tree, so it can be
>> a standalone C file instead of being scattered over all qemu.
> Did you look at the patchset I posted?

Very briefly only.

> Generation is in a standalone C file there.


> However, if you mean we should do things like
> if (Device_id == foobar) {
> }
> in once central place, I disagree.
> I think that's nasty, adding devices would
> mean touching this central registry.

No, I mean more "lookup PIIX4_PM object + check disable_s3 property"
instead of having code for it in hw/acpi/piix4.c or using global variables.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]