[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Date: Mon, 10 Jun 2013 19:51:55 -0500

Hi Kevin,

On Mon, Jun 10, 2013 at 7:23 PM, Kevin O'Connor <address@hidden> wrote:
> On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
>> Kevin O'Connor <address@hidden> writes:
>> For the MADT table, right now SeaBIOS needs the CPU count.  That can be
>> found by counting the number of CPU nodes.  Today cpus are unattached so
>> they appear in /machine/unattached but we should put them in a
>> /machine/cpu container for clarity.
> SeaBIOS needs much more than the CPU count.  The madt contains info on
> each interrupt - its global irq number, the legacy irq number, the
> acpi defined type of the irq, and the acpi defined flags for the irq.
> It also contains similar info on each cpu (including apic id), the io
> apic, and NMIs.

See below.

>> QOM is the full representation of the device state so we should not ever
>> need to add additional things to fw_cfg.  More likely than not, when
>> SeaBIOS needs more information, it's already there so added
>> functionality will probably Just Work with older QEMUs.
>> > I think it would also be
>> > useful if you could do the same for a couple DSDT entries (eg,
>> > \_SB.PCI0, \_SB.PCI0.ISA) and also describe how you plan to have the
>> > guest build the AML from that info.
>> Likewise the slot count should be available too.  We hard code slots
>> today but it is something we should model properly.  We would model it
>> using QOM of course.
>> Internally within QEMU, this initial discussion started by saying that
>> any ACPI generation within QEMU should happen strictly with QOM
>> methods.  This was the crux of my argument, if QOM is the only interface
>> we need, everything is there for the firmware to do the same job that
>> QEMU would be doing.
> I think we keep talking past each other.  You seem to be pointing out
> that the information seabios uses to patch its hardcoded tables can be
> passed in via QOM.  Agreed, it can.  I'm pointing out all the info
> that is hardcoded in seabios - I don't see how that can be passed via
> QOM.

No, we aren't talking past each other.  We both have the same goal.

A lot of what is hard coded in SeaBIOS is hard coded in QEMU too.  IRQ
routing is a good example of that.  We want to make this information

Part of the trouble is that we haven't had a need to not hard code it
because this is only information consumed by the BIOS.

> All the hardcoded data in seabios is a problem, because when it
> changes (and it frequently does) it requires changes to both QEMU and
> SeaBIOS and those changes have to be coordinated.  The key reason for
> moving the tables into QEMU is not that it can better patch the tables
> - the advantage is that it can hardcode the tables that need patching.

So let's fix it.  It's very easy to add read-only properties to QOM so
we can hard code the bits that are in SeaBIOS now as read-only
properties.  For the MADT table, the per-CPU and IOAPIC info can
simply be properties of those devices.  We already represent irqs in
QOM as integers so I suspect much of the information SeaBIOS needs is
already there.

> I can cite several recent examples of seabios change requests that
> require changing of the hardcoded tables: liguang wants to add an
> "embedded controller" hardware device which requires changes to
> seabios' dsdt, Corey Minyard wants to add IPMI hardware support (both
> smbios changes and DSDT changes), and Corey Bryant wants to add TPM
> hardware support.
> How do we solve the problem of seabios having a ton of hardcoded
> information about the qemu hardware, and seabios having to change with
> the hardware modifications that qemu makes?

I think that we can pretty much touch a table once pulling all of the
info from QOM and then from a SeaBIOS point of view, never have to
touch it again.

The benefit is that solving this problem for x86 solves it for other
architectures too and also lays the ground work to let a user actually
control these bits too.


Anthony Liguori

> -Kevin

reply via email to

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