Re: [Qemu-discuss] ppc and icount

[Steven Seeger]

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 <address@hidden>
Date:   Mon Dec 4 22:25:43 2017 +0000

    target/ppc: Fix system lockups caused by interrupt_request state 
corruption
    
    Occasionally in Linux guests on x86_64 we're seeing logs like:
    
    ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 
00000004
    
    when they should read:
    
    ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 00000100req 
00000002
    
    The "00000004" is CPU_INTERRUPT_EXITTB yet the code calls
    cpu_interrupt(cs, CPU_INTERRUPT_HARD) ("00000002") in this function
    just before the log message. Something is causing the HARD bit setting
    to get lost.
    
    The knock on effect of losing that bit is the decrementer timer interrupts
    don't get delivered which causes the guest to sit idle in its idle handler
    and 'hang'.
    
    The issue occurs due to races from code which sets CPU_INTERRUPT_EXITTB.
    
    Rather than poking directly into cs->interrupt_request, that code needs 
to:
    
    a) hold BQL
    b) use the cpu_interrupt() helper
    
    This patch fixes the call sites to do this, fixing the hang. The calls
    are made from a variety of contexts so a helper function is added to 
handle
    the necessary locking. This can likely be improved and optimised in the 
future
    but it ensures the code is correct and doesn't lockup as it stands today.
    
    Signed-off-by: Richard Purdie <address@hidden>
    Signed-off-by: David Gibson <address@hidden>

:040000 040000 0d422b95967a873ad8c9c549322bbb441ce8358a 
56ccf308d04930cf10745c7f65be1237dbb3554f M      target