On Wed, Jun 16, 2010 at 08:55:05PM -0400, Kevin O'Connor wrote:
On Tue, Jun 15, 2010 at 07:41:02AM +0300, Avi Kivity wrote:
On 06/14/2010 09:25 PM, Kevin O'Connor wrote:
This seems to be a philosophical distinction. Lets go over the
practical implications.
In my experience, well-defined
Avi Kivity wrote:
In general, ACPI code can work with memory or device registers that have
been initialized by the BIOS and depend on them. It's possible to write
ACPI code that depends on preceding BIOS code.
It's also possible to write C code that makes extensive use of goto. :)
To be
On Wed, Jun 16, 2010 at 09:22:09PM -0400, Kevin O'Connor wrote:
On Tue, Jun 15, 2010 at 09:37:07AM +0300, Gleb Natapov wrote:
On Mon, Jun 14, 2010 at 04:12:32PM -0400, Kevin O'Connor wrote:
But.. in order to move to a newer ACPI spec, there would be qemu
changes anyway. (If nothing else,
On Tue, Jun 15, 2010 at 07:41:02AM +0300, Avi Kivity wrote:
On 06/14/2010 09:25 PM, Kevin O'Connor wrote:
This seems to be a philosophical distinction. Lets go over the
practical implications.
In my experience, well-defined interfaces (philosophical
distinctions) are more important in the
On Tue, Jun 15, 2010 at 09:37:07AM +0300, Gleb Natapov wrote:
On Mon, Jun 14, 2010 at 04:12:32PM -0400, Kevin O'Connor wrote:
But.. in order to move to a newer ACPI spec, there would be qemu
changes anyway. (If nothing else, so that qemu can tell seabios if
it's okay to use the new rev.)
On Tue, Jun 15, 2010 at 09:50:48AM +0300, Gleb Natapov wrote:
On Tue, Jun 15, 2010 at 07:47:55AM +0300, Avi Kivity wrote:
One of Kevin's points was that the ACPI tables are a documented
interface. AFAIR, the firmware configuration interface isn't. We
need to start documenting it (and
My background is that of a strong coreboot proponent.
Gleb Natapov wrote:
So why not go further? In theory qemu needs seabios only for legacy bios
functionality. Qemu is perfectly capable of configuring HW to OS usable
state by itself, so we can have coreboot functionality completely inside
On 06/17/2010 04:47 AM, Kevin O'Connor wrote:
BTW, it's been said several times now that ACPI is an interface
between OS and firmware. I don't see this at all - ACPI defines how
the OS can interact with the hardware. The only place I know of where
seabios has involvement is with it's tiny (16
On Mon, Jun 14, 2010 at 04:12:32PM -0400, Kevin O'Connor wrote:
On Mon, Jun 14, 2010 at 09:56:15PM +0300, Gleb Natapov wrote:
On Mon, Jun 14, 2010 at 02:25:21PM -0400, Kevin O'Connor wrote:
It seems there was a change in qemu to the hpet functionality.
My patch is completely unrelated to
On Tue, Jun 15, 2010 at 07:47:55AM +0300, Avi Kivity wrote:
On 06/14/2010 10:38 PM, Anthony Liguori wrote:
I think we can be pretty flexible as long as we're careful about
releases. For instance, I've applied Gleb's current patch but
won't update SeaBIOS until the interface is worked out.
On Mon, Jun 14, 2010 at 11:30:53AM +0300, Gleb Natapov wrote:
Load hpet info for HPET ACPI table from qemu instead of using hardcoded
values. Use hardcoded values anyway if old qemu is detected.
The current code does a lot of mixing of qemu provided and seabios
provided data to build the acpi
On Mon, Jun 14, 2010 at 03:40:16PM +0100, Jamie Lokier wrote:
Gleb Natapov wrote:
On Mon, Jun 14, 2010 at 09:54:25AM -0400, Kevin O'Connor wrote:
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
On Mon, Jun 14, 2010 at 05:51:27PM +0300, Avi Kivity wrote:
On 06/14/2010 05:09 PM, Gleb Natapov wrote:
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
Possible, and I considered that. I personally
On Mon, Jun 14, 2010 at 02:25:21PM -0400, Kevin O'Connor wrote:
On Mon, Jun 14, 2010 at 05:51:27PM +0300, Avi Kivity wrote:
On 06/14/2010 05:09 PM, Gleb Natapov wrote:
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the
On 06/14/2010 01:25 PM, Kevin O'Connor wrote:
On Mon, Jun 14, 2010 at 05:51:27PM +0300, Avi Kivity wrote:
On 06/14/2010 05:09 PM, Gleb Natapov wrote:
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables()
On Mon, Jun 14, 2010 at 09:56:15PM +0300, Gleb Natapov wrote:
On Mon, Jun 14, 2010 at 02:25:21PM -0400, Kevin O'Connor wrote:
It seems there was a change in qemu to the hpet functionality.
My patch is completely unrelated to functionality change in qemu. In
fact I wrote it before the change
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
Possible, and I considered that. I personally prefer to pass minimum
information required for seabios to discover underlying HW and leave
ACPI
On 06/14/2010 09:25 PM, Kevin O'Connor wrote:
On Mon, Jun 14, 2010 at 05:51:27PM +0300, Avi Kivity wrote:
On 06/14/2010 05:09 PM, Gleb Natapov wrote:
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables()
On 06/14/2010 10:38 PM, Anthony Liguori wrote:
I think we can be pretty flexible as long as we're careful about
releases. For instance, I've applied Gleb's current patch but won't
update SeaBIOS until the interface is worked out. If we decide to
implement a new interface, there's no harm
19 matches
Mail list logo
