[Bug 1859384] Re: arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always re

2020-01-17 Thread Alex Longwall
** Summary changed: - arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq + arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-13 Thread Alex Longwall
Please find attached a test case reproducing this issue. (this is a variant of https://github.com/rhdrjones/kvm-unit- tests/blob/master/arm/pl031.c but for multiple CPUs) ** Attachment added: "Test case (kvm-unit-tests)"

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-13 Thread Alex Longwall
Err, I meant 3.2 subitem 5 "Note" "In a multiprocessor implementation, the GIC handles(...)" too, sorry -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1859384 Title: arm gic: interrupt model never

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-13 Thread Alex Longwall
For 2): since I've never written to ispendr, the level interrupt is still considered as pending on the other core because GIC_DIST_TEST_LEVEL(...) evaluates to true. I believe ack should clear the level on other cores for 1-n interrupts > For part (2), I think you're saying that we're missing

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-13 Thread Alex Longwall
> about describing the expected versus actual behaviour you see. Expected behavior: * core 0 (or 1) reads irqId (irqId becomes active/active-pending) * core 1 (or resp. 0) reads 1023 * core 0 handles and deactivates the interrupt What I am getting instead: * core 0 reads irqId * core 1 also

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-13 Thread Alex Longwall
> You might find there is enough in kvm-unit-tests GIC tests already to build a test case for what you are seeing. Right, I will do so as soon as possible. For bug 1) however, a simpler test can be made _start: // x0=gicd mov x0, #0x0800 // Read icfgr[for irqid=32...] ldr

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-12 Thread Alex Longwall
** Summary changed: - arm gicv2: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq + arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq ** Tags removed: gicv2 ** Tags added: gic -- You received this bug notification because

[Bug 1859384] [NEW] arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

2020-01-12 Thread Alex Longwall
Public bug reported: For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM, only one CPU can acknowledge the IRQ until it becomes inactive. The TRM also mandates that SGIs and PPIs follow the N-N model and that SPIs follow the 1-N model. However this is not currently the case with

[Bug 1859021] [NEW] qemu-system-aarch64 (tcg): cval + voff overflow not handled, causes qemu to hang

2020-01-09 Thread Alex Longwall
Public bug reported: The Armv8 architecture reference manual states that for any timer set (e.g. CNTP* and CNTV*), the condition for such timer to generate an interrupt (if enabled & unmasked) is: CVAL <= CNT(P/V)CT Although this is arguably sloppy coding, I have seen code that is therefore