[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/3] pseries: Fix bug with reset of V
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/3] pseries: Fix bug with reset of VIO CRQs |
Date: |
Thu, 5 Apr 2012 11:12:12 +1000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Apr 04, 2012 at 06:13:36PM +0200, Andreas Färber wrote:
> Am 28.03.2012 23:39, schrieb David Gibson:
> > PAPR specifies a Command Response Queue (CRQ) mechanism used for virtual
> > IO, which we implement. However, we don't correctly clean up registered
> > CRQs when we reset the system.
> >
> > 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 problem
> > down.
> >
> > Signed-off-by: David Gibson <address@hidden>
> > ---
>
> 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:
>
> 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,
>
> /* 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;
> }
>
> /* 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 = queue_addr;
>
> 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`:
>
> a) 0 > reset-all
> results in: "reboot not available Aborted"
> Do you need to update SLOF to actually use the newly added RTAS call?
>
> b) (qemu) system_reset
> results in:
> exception 700
> SRR0 = 0000000000000000 SRR1 = 800000008000000000080000
> SPRG2 = 0000000000000000 SPRG3 = 000000003DCD1AD4
>
> 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.
--
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