On Mon, Jun 10, 2013 at 08:25:15PM -0500, Anthony Liguori wrote:
I do understand your desire to pass this stuff as parameters, but I really don't see it as feasible. I'm hoping that if you can write up some examples with specifics you'll either enlighten me or you'll see the difficulties I'm trying to describe.
Is your basic argument that generating these tables is hard, QEMU can and should just hard code them and change them whenever it feels like without involving SeaBIOS?
Basically I think it makes sense to listen to people that write drivers for PV hardware that QEMU exposes. bios is one such example.
If people that are supposed to use our interfaces ask for a specific interface, I think we should listen. If people come and say that building acpi dynamically is hard for them and they want QEMU to prepare templates for acpi - and there's overwhelming concensus on this - QEMU should stop going "tough luck we know what's best for you".
If that's what it boils down to, I'll look more closely at it.
So please look at the original patchset [PATCH RFC 00/13] qemu: generate acpi tables for the guest
and let's move the discussion of it beyond the meta-argument "QEMU does not need to generate any ACPI tables" and to the specific interface that we can use to make life easier for the bios.
Specifically several options were discussed, on and off-line for passing per-formatted tables to firmware:
1. use existing fw cfg interface from bios, qemu side make it work well with cross version migration. 2. same as 1 but find some existing hardware that is similar to fw cfg and emulate it. For example build a directory structure in some flash. 3. make qemu put tables into guest memory. bios needs to reserve this memory. 4. same as 3 but bios allocates memory and passes address to qemu.
Kevin suggested 1. This is what my patchset implements. But I think bios could live with any of the others, as long as it's a generic interface so we can stop changing bios code all the time.
-
Michael S. Tsirkin