Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto:
Two points
1. You never explained what you mean by un-hardware like.
Currently bios is in a ROM device, and it has a
template for ACPI tables together with it.
This simply moves the tables to a separate ROM
device (FW CFG),
On 06/14/13 01:02, Paolo Bonzini wrote:
Il 10/06/2013 21:03, Anthony Liguori ha scritto:
I'm not really convinced that
QEMU-firmware is a GPL boundary because of how tightly the two are
linked.
Where has 'linked' in terms of the GPL ever been anything other than
actual executable linking?
Paolo Bonzini pbonz...@redhat.com writes:
Il 11/06/2013 03:35, Michael S. Tsirkin ha scritto:
Two points
1. You never explained what you mean by un-hardware like.
Currently bios is in a ROM device, and it has a
template for ACPI tables together with it.
This simply moves the
Anthony Liguori wrote:
However, with PCs, the ACPI tables are generated by/included in the
firmware. There's no question about that.
I think the key point is that the firmware is developed and delivered
by the hardware vendor, and not by an independent source.
The firmware is intimately tied
On Mon, 2013-06-10 at 19:11 -0500, Anthony Liguori wrote:
If we did this right in QEMU, we'd have to introduce a QOM property
anyway
... and then we'd have to update each firmware implementation to know
about this new property, and the how it translates to the RESET_REG
field in the DSDT, etc.
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
12 matches
Mail list logo
