qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: Avi Kivity <avi@redhat.com>
Cc: seabios@seabios.org, qemu-devel@nongnu.org,
	Gleb Natapov <gleb@redhat.com>
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu
Date: Mon, 14 Jun 2010 14:25:21 -0400	[thread overview]
Message-ID: <20100614182521.GA22454@morn.localdomain> (raw)
In-Reply-To: <4C1641EF.9070001@redhat.com>

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 prefer to pass minimum
> >information required for seabios to discover underlying HW and leave
> >ACPI table creation to seabios. That is how things done for HW that
> >seabios can actually detect. If we will go your way pretty soon we will
> >move creation of ACPI/SMBIOS/MP tables into qemu and IMHO this will be
> >step backworkds.
> 
> I agree.  ACPI is a firmware/OS interface.  If we move ACPI table
> generation into qemu, it becomes a mixed hardware/firmware/OS
> interface.

This seems to be a philosophical distinction.  Lets go over the
practical implications.

It seems there was a change in qemu to the hpet functionality.
Although the change is solely between qemu and the OS, it's necessary
to patch both qemu and seabios for the OS to see the change.  This
means creating and reviewing patches for two separate repos.  This
also requires release coordination - the seabios change has to be
committed and released, and then qemu needs to be released with the
new seabios.  Additional changes in seabios tip will get merged into
qemu, which could complicate testing.

> Better keep those interfaces separate: hardware/firmware (fwcfg) and
> firmware/OS (acpi).

One could look at the current hpet patch as implementing:
qemu -> struct hpet_fw_entry -> seabios -> struct acpi_20_hpet -> OS.

I'm suggesting that we do the following instead:
qemu -> struct acpi_20_hpet -> seabios -> struct acpi_20_hpet -> OS.

I'm not suggesting a radical rethink of fwcfg, but I fail to see the
advantage in introducing the arbitrary "struct hpet_fw_entry" when
there is a perfectly good, well defined, "struct acpi_20_hpet" that
already exists.  This new arbitrary intermediate format just
introduces "make work" for all of us.

-Kevin

  reply	other threads:[~2010-06-14 18:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-14  8:30 [Qemu-devel] [PATCHv2] load hpet info for HPET ACPI table from qemu Gleb Natapov
2010-06-14 13:54 ` [Qemu-devel] Re: [SeaBIOS] " Kevin O'Connor
2010-06-14 14:09   ` Gleb Natapov
2010-06-14 14:40     ` Jamie Lokier
2010-06-14 16:03       ` Gleb Natapov
2010-06-14 14:51     ` Avi Kivity
2010-06-14 18:25       ` Kevin O'Connor [this message]
2010-06-14 18:56         ` Gleb Natapov
2010-06-14 20:12           ` Kevin O'Connor
2010-06-15  6:37             ` Gleb Natapov
2010-06-17  1:22               ` Kevin O'Connor
2010-06-17  7:45                 ` Gleb Natapov
2010-06-17  1:58             ` Peter Stuge
2010-06-14 19:38         ` Anthony Liguori
2010-06-15  4:47           ` Avi Kivity
2010-06-15  6:50             ` Gleb Natapov
2010-06-17  1:47               ` Kevin O'Connor
2010-06-17  3:58                 ` Avi Kivity
2010-06-17  6:57                   ` Peter Stuge
2010-06-15  0:54         ` Paul Brook
2010-06-15  4:41         ` Avi Kivity
2010-06-17  0:55           ` Kevin O'Connor
2010-06-17  6:44             ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100614182521.GA22454@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).