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 nothi
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 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, wel
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
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 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 (an
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 r
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 i
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 worke
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 unrelat
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 si
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() me
> > >>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 an
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 chan
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() me
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 qemu_cfg_acpi_
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 p
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() me
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 prefer to pass minimum
information required for seabios to
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.
> >
> Possible, and I considered that. I personally prefer to p
On Mon, Jun 14, 2010 at 09:54:25AM -0400, Kevin O'Connor wrote:
> 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 l
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
22 matches
Mail list logo