[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
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients, (continued)
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients, Laszlo Ersek, 2013/04/26
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients, Michael S. Tsirkin, 2013/04/29
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients, Kevin O'Connor, 2013/04/29
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients, Laszlo Ersek, 2013/04/29
- Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients,
Michael S. Tsirkin <=
Re: [Qemu-devel] [PATCH v4 0/7] publish etc/acpi/APIC in fw_cfg, Laszlo Ersek, 2013/04/24