From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtKOB-00022X-46 for qemu-devel@nongnu.org; Wed, 18 Dec 2013 11:54:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtKO4-0006nQ-JG for qemu-devel@nongnu.org; Wed, 18 Dec 2013 11:54:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtKO4-0006n7-CR for qemu-devel@nongnu.org; Wed, 18 Dec 2013 11:54:20 -0500 Date: Wed, 18 Dec 2013 18:58:08 +0200 From: "Michael S. Tsirkin" Message-ID: <20131218165808.GC21916@redhat.com> References: <1386753670-11238-1-git-send-email-ghammer@redhat.com> <52B1AFC3.1050809@redhat.com> <20131218152227.GA21186@redhat.com> <1387384032.2585.7.camel@localhost.localdomain> <20131218163306.GB21916@redhat.com> <178534992.41571400.1387384454834.JavaMail.root@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <178534992.41571400.1387384454834.JavaMail.root@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] piix: do not reset APIC base address (0x80) on piix4_reset. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Gal Hammer , seabios@seabios.org, qemu-devel@nongnu.org, marcel a On Wed, Dec 18, 2013 at 11:34:14AM -0500, Paolo Bonzini wrote: >=20 >=20 > ----- Messaggio originale ----- > > Da: "Michael S. Tsirkin" > > A: "marcel a" > > Cc: "Paolo Bonzini" , "Gal Hammer" , seabios@seabios.org, > > qemu-devel@nongnu.org > > Inviato: Mercoled=C3=AC, 18 dicembre 2013 17:33:06 > > Oggetto: Re: [Qemu-devel] [PATCH] piix: do not reset APIC base addres= s (0x80) on piix4_reset. > >=20 > > On Wed, Dec 18, 2013 at 06:27:12PM +0200, Marcel Apfelbaum wrote: > > > On Wed, 2013-12-18 at 17:22 +0200, Michael S. Tsirkin wrote: > > > > On Wed, Dec 18, 2013 at 03:22:59PM +0100, Paolo Bonzini wrote: > > > > > Il 11/12/2013 10:21, Gal Hammer ha scritto: > > > > > > Fix a bug that was introduced in commit c046e8c4. QEMU fails = to > > > > > > resume from suspend mode (S3). > > > > > >=20 > > > > > > Signed-off-by: Gal Hammer > > > > > > --- > > > > > > hw/acpi/piix4.c | 1 - > > > > > > 1 file changed, 1 deletion(-) > > > > > >=20 > > > > > > diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c > > > > > > index 93849c8..5c736a4 100644 > > > > > > --- a/hw/acpi/piix4.c > > > > > > +++ b/hw/acpi/piix4.c > > > > > > @@ -376,7 +376,6 @@ static void piix4_reset(void *opaque) > > > > > > pci_conf[0x5b] =3D 0; > > > > > > =20 > > > > > > pci_conf[0x40] =3D 0x01; /* PM io base read only bit */ > > > > > > - pci_conf[0x80] =3D 0; > > > > > > =20 > > > > > > if (s->kvm_enabled) { > > > > > > /* Mark SMM as already inited (until KVM supports SM= M). */ > > > > >=20 > > > > > Note this is not the APIC base address, that one is 80h on the = ISA > > > > > bridge (function 0). You're changing the behavior for 80h on t= he power > > > > > management function, which is function 3. The register is "PMB= A=E2=80=94POWER > > > > > MANAGEMENT BASE ADDRESS" and it is indeed initialized by SeaBIO= S in > > > > > piix4_pm_setup (src/fw/pciinit.c). > > > > >=20 > > > > > Michael, perhaps a part of pci_setup (same file) should run on = S3 > > > > > resume? > > > > >=20 > > > > > Paolo > > > >=20 > > > > Seems reasonable: either seabios or guest OS must do it, and > > > > guest does not seem to. > > > I was looking into this today, but it seems that we have a problem. > > > We cannot run pci_setup() in init section: > > > .data.varinit.seabios/src/hw/pci.h.66 is VARVERIFY32INIT but used f= rom > > > ['.text.runtime.seabios/src/resume.c.150', '.text.pci_setup'] > > >=20 > > > Any thoughts how to get around this? > > > Thanks, > > > Marcel > >=20 > > We defintely don't want to do full pci enumeration. > > Just pci_bios_init_platform or even less. >=20 > Or put an array of (bdf, offset, size, value) tuples somewhere in low m= emory, > fill it at startup, and reproduce it blindly at S3 resume time. This i= s similar > to what UEFI does. >=20 > Paolo Yes, it's an option. Though reworking pci_bios_init_devices so that it can work from low memory seems easier.