From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFc3m-00031X-DN for qemu-devel@nongnu.org; Wed, 04 Apr 2012 22:04:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFc3f-0004oc-DL for qemu-devel@nongnu.org; Wed, 04 Apr 2012 22:04:25 -0400 Date: Thu, 5 Apr 2012 11:12:12 +1000 From: David Gibson Message-ID: <20120405011212.GC19379@truffala.fritz.box> References: <1332970787-14598-1-git-send-email-david@gibson.dropbear.id.au> <1332970787-14598-2-git-send-email-david@gibson.dropbear.id.au> <4F7C7330.1080400@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4F7C7330.1080400@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/3] pseries: Fix bug with reset of VIO CRQs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: scottwood@freescale.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Wed, Apr 04, 2012 at 06:13:36PM +0200, Andreas F=E4rber wrote: > Am 28.03.2012 23:39, schrieb David Gibson: > > PAPR specifies a Command Response Queue (CRQ) mechanism used for virt= ual > > IO, which we implement. However, we don't correctly clean up registe= red > > CRQs when we reset the system. > >=20 > > This patch adds a reset handler to fix this bug. While we're at it, = add > > in some of the extra debug messages that were used to track the probl= em > > down. > >=20 > > Signed-off-by: David Gibson > > --- >=20 > As discussed on IRC, I've applied the following diff on my local branch > to drop the h_reg_crq that my __func__ comment was about: >=20 > diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c > index 0bf2c31..97d029a 100644 > --- a/hw/spapr_vio.c > +++ b/hw/spapr_vio.c > @@ -431,13 +431,13 @@ static target_ulong h_reg_crq(CPUPPCState *env, > sPAPREnvironment *spapr, >=20 > /* Check if device supports CRQs */ > if (!dev->crq.SendFunc) { > - hcall_dprintf("Device does not support CRQ\n"); > + hcall_dprintf("h_reg_crq, device does not support CRQ\n"); > return H_NOT_FOUND; > } >=20 > /* Already a queue ? */ > if (dev->crq.qsize) { > - hcall_dprintf("CRQ already registered\n"); > + hcall_dprintf("h_reg_crq, CRQ already registered\n"); > return H_RESOURCE; > } > dev->crq.qladdr =3D queue_addr; >=20 > However, I'm having trouble testing reset. Whether on vanilla master or > using this patch on top of ppc-next or this whole series on top of > ppc-next, using `ppc64-softmmu/qemu-system-ppc64 -M pseries -m 1G`: >=20 > a) 0 > reset-all > results in: "reboot not available Aborted" > Do you need to update SLOF to actually use the newly added RTAS call? >=20 > b) (qemu) system_reset > results in: > exception 700 > SRR0 =3D 0000000000000000 SRR1 =3D 800000008000000000080000 > SPRG2 =3D 0000000000000000 SPRG3 =3D 000000003DCD1AD4 >=20 > Could you please look into the two above issues? How did you test? Ah. I used "reboot" from within the guest Linux. I'll look at the others, the first could just be a slof bug. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other= _ | _way_ _around_! http://www.ozlabs.org/~dgibson