On Mon, Apr 29, 2013 at 08:39:26AM -0400, Kevin O'Connor wrote: > On Mon, Apr 29, 2013 at 11:20:15AM +0300, Michael S. Tsirkin wrote: > > On Fri, Apr 26, 2013 at 01:13:28PM +0200, Laszlo Ersek wrote: > > > > > > I added this from v3 to v4 because Michael asked me for it > > > <http://thread.gmane.org/gmane.comp.emulators.qemu/206435/focus=207146>. > > > > > > >From the SeaBIOS side, I believe Kevin O'Connor also wants to keep out > > > related code from SeaBIOS until a full set of tables is passed. I > > > disagree with flipping a big switch in the end (ie. I agree a config > > > option (let alone a separate SeaBIOS branch) is unwarranted, which is > > > why I didn't add the former in v3), but I have no say in it. > > > > > > Do you want me to rip out these hunks (and adapt the dependencies)? > > > > Essentially, what seabios wants to do is operate in two > > modes: > > - (mostly) use builtin acpi tables > > - use acpi tables from hypervisor > > > > in particular, seabios wants to interpret presence > > of any file in etc/acpi as a signal not to generate > > its own tables. > > Right. > > > So merging this patch but without the config option will break > > this plan. The only two ways I see are: > > - merge this last patch with the config option, disabled by default > > the idea being we can improve it in-tree, gradually. > > - keep this patch out of tree until we have a complete > > set of tables. > > > > Both are fine with me. > > Why? As long as QEMU places the new tables under new fwcfg entries, > old seabios will totally ignore the new tables. I don't see why a > QEMU config option is needed - it's safe for QEMU to always create > both old and new fwcfg entries. > > -Kevin
Yes backwards compatibility is fine, but the problem here is forwards compatibility. Future BIOS will say: "there's something in etc/acpi/ therefore I won't generate any tables" so we should not release QEMU that puts only MADT under etc/acpi/madt. -- MST