From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: KVM call agenda for 2013-05-28
Date: Wed, 29 May 2013 12:46:17 +0300
Message-ID: <20130529094616.GL4472@redhat.com>
References: <20130523124132.GA18596@redhat.com>
 <20130528235309.GA31648@morn.localdomain>
 <51A5C117.6000609@redhat.com> <20130529091723.GI4472@redhat.com>
 <51A5CD8A.1080801@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
 Juan Quintela <quintela@redhat.com>, seabios@seabios.org,
 qemu-devel qemu-devel <qemu-devel@nongnu.org>, dwmw2@infradead.org
To: Gerd Hoffmann <kraxel@redhat.com>
Return-path: <seabios-bounces@seabios.org>
Content-Disposition: inline
In-Reply-To: <51A5CD8A.1080801@redhat.com>
List-Unsubscribe: <http://www.seabios.org/mailman/options/seabios>,
 <mailto:seabios-request@seabios.org?subject=unsubscribe>
List-Archive: <http://www.seabios.org/pipermail/seabios>
List-Post: <mailto:seabios@seabios.org>
List-Help: <mailto:seabios-request@seabios.org?subject=help>
List-Subscribe: <http://www.seabios.org/mailman/listinfo/seabios>,
 <mailto:seabios-request@seabios.org?subject=subscribe>
Errors-To: seabios-bounces@seabios.org
Sender: seabios-bounces@seabios.org
List-Id: kvm.vger.kernel.org

On Wed, May 29, 2013 at 11:42:34AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >>> possible complexity of having to regenerate
> >>> tables on a vm reboot,
> >>
> >> Why tables should be regenerated at reboot?  I remember hotplug being
> >> mentioned in the call.  Hmm?  Which hotplugged component needs acpi
> >> table updates to work properly?  And what is the point of hotplugging if
> >> you must reboot the guest anyway to get the acpi updates needed?
> >> Details please.
> > 
> > I think it's a mistake. I sent a mail explaining this part.
> 
> Saw it meanwhile.
> 
> >> Also mentioned in the call: "architectural reasons", which I understand
> >> as "real hardware works that way".  Correct.
> > 
> > Not exactly. Real hardware is very likely to have
> > most of the tables pre-generated in ROM, load
> > them and tweak them in the minor way.
> 
> >From a quick look it seems coreboot has a static (iasl-compiled) dsdt
> and generates everything else.
> 
> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/emulation/qemu-x86/acpi_tables.c
> 
> >> Agree on this one.  Ideally the acpi table generation code should be
> >> able to gather all information it needs from the qom tree, so it can be
> >> a standalone C file instead of being scattered over all qemu.
> > 
> > Did you look at the patchset I posted?
> 
> Very briefly only.
> 
> > Generation is in a standalone C file there.
> 
> Good.
> 
> > However, if you mean we should do things like
> > 
> > if (Device_id == foobar) {
> > }
> > in once central place, I disagree.
> > I think that's nasty, adding devices would
> > mean touching this central registry.
> 
> No, I mean more "lookup PIIX4_PM object + check disable_s3 property"
> instead of having code for it in hw/acpi/piix4.c or using global variables.
> 
> cheers,
>   Gerd

So that would make code PIIX specific.
Instead I'm passing in guest_info structure to each object
and that describes itself, e.g. sets disable_s3.

-- 
MST