Re: [Qemu-devel] [PATCH v2 repost 8/9] i386: generate pc guest info

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 24, 2013 at 05:36:58PM +0200, Laszlo Ersek wrote:
> On 07/17/13 17:07, Laszlo Ersek wrote:
> > On 07/10/13 15:51, Michael S. Tsirkin wrote:
> >> This fills in guest info table with misc
> >> information of interest to the guest.
> >> Will be used by ACPI table generation code.
> >>
> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >> ---
> >>  hw/acpi/ich9.c         |  7 ++++++-
> >>  hw/acpi/piix4.c        | 44 +++++++++++++++++++++++++++++++++++++++++++-
> >>  hw/i386/Makefile.objs  |  2 ++
> >>  hw/i386/pc.c           | 41 +++++++++++++++++++++++++++++++++++++++--
> >>  hw/i386/pc_piix.c      | 15 ++++++++++++---
> >>  hw/i386/pc_q35.c       | 10 +++++++---
> >>  hw/isa/lpc_ich9.c      | 11 +++++++++--
> >>  hw/mips/mips_malta.c   |  2 +-
> >>  hw/misc/pvpanic.c      | 12 +++++++-----
> >>  hw/pci-host/q35.c      |  1 +
> >>  include/hw/acpi/ich9.h |  2 +-
> >>  include/hw/i386/ich9.h |  3 ++-
> >>  include/hw/i386/pc.h   | 37 ++++++++++++++++++++++++++++++++++---
> >>  13 files changed, 164 insertions(+), 23 deletions(-)
> > 
> > So we won't be fishing in a global pool of information at ACPI table
> > creation time as I had expected / advertized before. Instead any
> > required bits are gradually collected into the guest info structure
> > while creating / configuring the machine.
> > 
> > This is likely a better approach; the set of dependencies for all ACPI
> > tables together are tracked explicitly in guest info. Also, we don't
> > collect the bits from the outside, breaching encapsulation of devices;
> > devices publish the bits.
> > 
> > Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> 
> If I understand correctly, based on the recent comments you got from
> Gerd and Andreas for this series (in the other, non-repost thread),
> fishing in the global pool it should be after all, just with a different
> fishing rod than what I used in my original patch ("hw/i386: build ACPI
> MADT (APIC) for fw_cfg clients").
> 
> These U-turns in design have proved that I'm not qualified to review
> this work. So I won't; there's no use in my repeated saying "yeah why
> not" to both approaches (which are polar opposites). My apologies.
> 
> I applaud your perseverance in this matter.
> 
> Laszlo

Thanks for all your comments so far,

-- 
MST