qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_c


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients
Date: Mon, 29 Apr 2013 16:21:08 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]