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: Kevin O'Connor
Subject: Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients
Date: Mon, 29 Apr 2013 08:39:26 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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