[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: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Date: Mon, 10 Jun 2013 20:23:05 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
> Kevin O'Connor <address@hidden> writes:
> > On Mon, Jun 10, 2013 at 04:45:53PM -0500, Anthony Liguori wrote:
> >> This discussion comes down to two things I think: (a) our existing
> >> firmware interface is pretty poor (b) we are duplicating work because of
> >> firmware licensing.
> >> 
> >> We can fix (a) and there's lots of value in doing that in terms of
> >> improving support for other architectures.  We've discussed (b) in other
> >> threads and I've stated my opinion on the direction we need to take.
> >
> > I'm not concerned about (b).
> >
> > I'm quite curious how you are planning to solve (a).  I think it would
> > help move this conversation forward if you could take a couple acpi
> > tables in use today (eg, madt, srat) and describe the future format
> > and location for each field in those tables.
> Sure.  Today we expose the device model through a graph that can be
> losely mapped to a filesystem.  We expose two methods of interest as
> part of our management api:
> 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.

> 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

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.

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?


reply via email to

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