Re: [Qemu-devel] [Qemu-discuss] ppc and icount

Re: [Qemu-devel] [Qemu-discuss] ppc and icount

[Peter Maydell]

On 10 January 2018 at 08:57, Steven Seeger
<steven.seeger@flightsystems.net> wrote:
> Sorry for another post. I did a bisect and found what is the bad commit for
> me:
>
> 044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
> commit 044897ef4a22af89aecb8df509477beba0a2e0ce
> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
> Date:   Mon Dec 4 22:25:43 2017 +0000
>
>     target/ppc: Fix system lockups caused by interrupt_request state
> corruption

Great -- thanks for the bisect. Let's take this to the -devel list;
I've cc'd the PPC maintainers.

Context: Steven reports that we broke -icount for PPC guests with
this commit:

$ ./build/all/ppc-softmmu/qemu-system-ppc  -icount auto
qemu: fatal: Raised interrupt while not in I/O function
NIP fff08978   LR fff08904 CTR 00000000 XER 00000000 CPU#0
MSR 00000000 HID0 00000000  HF 00000000 iidx 3 didx 3
Bad icount read

The backtrace from the assert is:

#0  tcg_handle_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/accel/tcg/tcg-
all.c:58
#1  0x0000555555962aa4 in cpu_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/
include/qom/cpu.h:859
#2  0x0000555555962e55 in cpu_interrupt_exittb (cs=0x7ffff7fc2010) at qemu/
target/ppc/helper_regs.h:105
#3  0x0000555555964505 in do_rfi (env=0x7ffff7fca2b0, nip=197460, msr=4096)
    at qemu/target/ppc/excp_helper.c:998
#4  0x0000555555964555 in helper_rfi (env=0x7ffff7fca2b0) at qemu/target/ppc/
excp_helper.c:1008
#5  0x00007fffe7c124b9 in code_gen_buffer ()

The problem is that icount was relying on the previous
handling of do_rfi() as "just set state as we know we're
going to be last insn in the TB".

Not sure how best to fix this (mark the insn as IO ok?)

thanks
-- PMM

Re: [Qemu-devel] [Qemu-discuss] ppc and icount

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

On Wed, Jan 10, 2018 at 10:34:18AM +0000, Peter Maydell wrote:
> On 10 January 2018 at 08:57, Steven Seeger
> <steven.seeger@flightsystems.net> wrote:
> > Sorry for another post. I did a bisect and found what is the bad commit for
> > me:
> >
> > 044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
> > commit 044897ef4a22af89aecb8df509477beba0a2e0ce
> > Author: Richard Purdie <richard.purdie@linuxfoundation.org>
> > Date:   Mon Dec 4 22:25:43 2017 +0000
> >
> >     target/ppc: Fix system lockups caused by interrupt_request state
> > corruption
> 
> Great -- thanks for the bisect. Let's take this to the -devel list;
> I've cc'd the PPC maintainers.
> 
> Context: Steven reports that we broke -icount for PPC guests with
> this commit:
> 
> $ ./build/all/ppc-softmmu/qemu-system-ppc  -icount auto
> qemu: fatal: Raised interrupt while not in I/O function
> NIP fff08978   LR fff08904 CTR 00000000 XER 00000000 CPU#0
> MSR 00000000 HID0 00000000  HF 00000000 iidx 3 didx 3
> Bad icount read
> 
> The backtrace from the assert is:
> 
> #0  tcg_handle_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/accel/tcg/tcg-
> all.c:58
> #1  0x0000555555962aa4 in cpu_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/
> include/qom/cpu.h:859
> #2  0x0000555555962e55 in cpu_interrupt_exittb (cs=0x7ffff7fc2010) at qemu/
> target/ppc/helper_regs.h:105
> #3  0x0000555555964505 in do_rfi (env=0x7ffff7fca2b0, nip=197460, msr=4096)
>     at qemu/target/ppc/excp_helper.c:998
> #4  0x0000555555964555 in helper_rfi (env=0x7ffff7fca2b0) at qemu/target/ppc/
> excp_helper.c:1008
> #5  0x00007fffe7c124b9 in code_gen_buffer ()
> 
> The problem is that icount was relying on the previous
> handling of do_rfi() as "just set state as we know we're
> going to be last insn in the TB".
> 
> Not sure how best to fix this (mark the insn as IO ok?)

Aw, man.  I've become target-ppc tcg maintainer by default, but tbh my
knowledge wasn't really deep enough to understand the problem that
044897ef was fixing in the first place.  And I barely know what icount
does at all.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [Qemu-discuss] ppc and icount

[Laurent Vivier]

On 10/01/2018 11:34, Peter Maydell wrote:
> On 10 January 2018 at 08:57, Steven Seeger
> <steven.seeger@flightsystems.net> wrote:
>> Sorry for another post. I did a bisect and found what is the bad commit for
>> me:
>>
>> 044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
>> commit 044897ef4a22af89aecb8df509477beba0a2e0ce
>> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>> Date:   Mon Dec 4 22:25:43 2017 +0000
>>
>>     target/ppc: Fix system lockups caused by interrupt_request state
>> corruption
> 
> Great -- thanks for the bisect. Let's take this to the -devel list;
> I've cc'd the PPC maintainers.
> 
> Context: Steven reports that we broke -icount for PPC guests with
> this commit:
> 
> $ ./build/all/ppc-softmmu/qemu-system-ppc  -icount auto
> qemu: fatal: Raised interrupt while not in I/O function
> NIP fff08978   LR fff08904 CTR 00000000 XER 00000000 CPU#0
> MSR 00000000 HID0 00000000  HF 00000000 iidx 3 didx 3
> Bad icount read
> 
> The backtrace from the assert is:
> 
> #0  tcg_handle_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/accel/tcg/tcg-
> all.c:58
> #1  0x0000555555962aa4 in cpu_interrupt (cpu=0x7ffff7fc2010, mask=4) at qemu/
> include/qom/cpu.h:859
> #2  0x0000555555962e55 in cpu_interrupt_exittb (cs=0x7ffff7fc2010) at qemu/
> target/ppc/helper_regs.h:105
> #3  0x0000555555964505 in do_rfi (env=0x7ffff7fca2b0, nip=197460, msr=4096)
>     at qemu/target/ppc/excp_helper.c:998
> #4  0x0000555555964555 in helper_rfi (env=0x7ffff7fca2b0) at qemu/target/ppc/
> excp_helper.c:1008
> #5  0x00007fffe7c124b9 in code_gen_buffer ()
> 
> The problem is that icount was relying on the previous
> handling of do_rfi() as "just set state as we know we're
> going to be last insn in the TB".
> 
> Not sure how best to fix this (mark the insn as IO ok?)

According to what I see for other targets I think we should add a
POWERPC_EXCP_RFI and call do_rfi() and friends from powerpc_excp().

Thanks,
Laurent