From: Kevin O'Connor <kevin@koconnor.net>
To: Gleb Natapov <gleb@redhat.com>
Cc: seabios@seabios.org, Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu
Date: Wed, 16 Jun 2010 21:47:30 -0400 [thread overview]
Message-ID: <20100617014729.GC1081@morn.localdomain> (raw)
In-Reply-To: <20100615065047.GL21797@redhat.com>
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 reject patches without
> > accompanying documentation).
> ACPI tables are, indeed, documented interface (it doesn't make it good
> interface though :)), but it is interface between firmware and OS, so
> it may (and it does) have things like "if firmware support that, then
> this bit should be set". Using it as interface to describe HW to
> firmware is just plain abuse.
I also don't much like the ACPI spec. In particular, the DSDT stuff
is just crazy. However, the other tables (eg, hpet, srat, madt, fadt,
facs) are just your bog standard binary structs. There really is no
fundamental difference between these formats and the structs currently
passed via fwcfg.
I don't think it is an abuse to configure the firmware with these
structures. They define necessary information that can't be
auto-detected, so they're going to have a lot of overlap with info
that needs to be passed between qemu and firmware. The tables are not
perfect, but neither are the alternatives. The mature documentation
and the fact that it is an industry standard makes up for many of
their deficiencies.
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 asm statement) SMI stub.
Everything else describes the hardware and enables interactions
directly with the hardware.
-Kevin
next prev parent reply other threads:[~2010-06-17 1:47 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
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 [this message]
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=20100617014729.GC1081@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).