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