This adds support for device hotplug behind
pci bridges. Bridge devices themselves need
to be pre-configured on qemu command line.
One of the goals of this project was to
demonstrate the advantages of generating
ACPI tables in QEMU.
In my opinion, it does this successfully.
* This saves
Michael S. Tsirkin m...@redhat.com writes:
This adds support for device hotplug behind
pci bridges. Bridge devices themselves need
to be pre-configured on qemu command line.
One of the goals of this project was to
demonstrate the advantages of generating
ACPI tables in QEMU.
In my
On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
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
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
David Woodhouse dw...@infradead.org writes:
On Mon, 2013-06-10 at 18:34 -0500, Anthony Liguori wrote:
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
Hi Kevin,
On Mon, Jun 10, 2013 at 7:23 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Mon, Jun 10, 2013 at 06:34:29PM -0500, Anthony Liguori wrote:
Kevin O'Connor ke...@koconnor.net writes:
For the MADT table, right now SeaBIOS needs the CPU count. That can be
found by counting the number
On Mon, Jun 10, 2013 at 01:58:41PM -0500, Anthony Liguori wrote:
Michael S. Tsirkin m...@redhat.com writes:
This adds support for device hotplug behind
pci bridges. Bridge devices themselves need
to be pre-configured on qemu command line.
One of the goals of this project was to