On Thu, May 30, 2013 at 01:19:18PM +0100, David Woodhouse wrote: > Yeah, but if we're shoving a lot of hardware-specific ACPI table > generation into the guest's firmware, instead of just doing it on the > qemu side where a number of us seem to think it belongs, Hopefully this is not yet set in stone. > then there *is* > a benefit to using Coreboot. When stuff changes on the qemu side and we > have to update the table generation to match, you end up having to > update just the Coreboot package, and *not* having to patch both SeaBIOS > and OVMF. We have all kind of logic in qemu. Some of it can thinkably be moved to a separate VM - it doesn't even need to run in the same VM as the guest - we could do it e.g. like kvm unit-test does, with less pain than running it in firmware. Not clear why would generating ACPI tables - which merely fills up an array of bytes from internal QEMU datastructures - should be the part where we start this modularization. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
