diff for duplicates of <87k15vo4i7.fsf@linaro.org> diff --git a/a/1.txt b/N1/1.txt index 1778a01..9cb09a1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,4 +1,3 @@ - Alex Longwall <1859384@bugs.launchpad.net> writes: > Public bug reported: @@ -212,3 +211,81 @@ applies to all mmio emulated devices. -- Alex Bennée + +-- +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 1 on non-mpcore and race condition in + gic_acknowledge_irq + +Status in QEMU: + New + +Bug description: + 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 QEMU. I have locally (no + minimal test case) seen e.g. uart interrupts being acknowledged twice + before having been deactivated (expected: irqId on one CPU and 1023 on + the other instead). + + I have narrowed the issue down to the following: + + 1) arm_gic_common_reset resets all irq_state[id] fields to 0. This + means all IRQ will use the N-N model, and if s->revision != + REV_11MPCORE, then there's no way to set any interrupt to 1-N. + + If ""fixed"" locally with a hackjob, I still have the following trace: + + pl011_irq_state 534130.800 pid=2424 level=0x1 + gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff + gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1 + gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1 + gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21 + gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1 + gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21 + gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21 + gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21 + pl011_write 1594.700 pid=2424 addr=0x44 value=0x50 + pl011_irq_state 2.000 pid=2424 level=0x0 + gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff + pl011_write 30.700 pid=2424 addr=0x38 value=0x0 + pl011_irq_state 1.200 pid=2424 level=0x0 + gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21 + gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21 + pl011_irq_state 1169.500 pid=2424 level=0x0 + + This is because: + + 2) gic_acknowledge_irq calls gic_clear_pending which uses + GIC_DIST_CLEAR_PENDING but this usually has no effect on level- + sensitive interrupts. + + With this often being a no-op (ie. assuming ispendr was not written + to), any 1-n level-sensitive interrupt is still improperly pending on + all the other cores. + + (Also, I don't really know how the qemu thread model works, there + might be race conditions in the acknowledgment logic if + gic_acknowledge_irq is called by multiple threads, too.) + + Option used: + -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024 + -kernel whatever.elf -d unimp,guest_errors -semihosting-config enable,target=native + -chardev stdio,id=uart -serial chardev:uart -monitor none + -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state -trace pl011_write -trace gic_cpu_read -trace gic_cpu_write + -trace gic_set_irq + + Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote- + tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into + staging" + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1859384/+subscriptions diff --git a/a/content_digest b/N1/content_digest index 4981d32..4e76544 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,12 +1,10 @@ "ref\0157887973843.5281.117317310678495552.malonedeb@gac.canonical.com\0" "From\0Alex Benn\303\251e <alex.bennee@linaro.org>\0" "Subject\0Re: [Bug 1859384] [NEW] arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq\0" - "Date\0Mon, 13 Jan 2020 13:44:16 +0000\0" - "To\0Bug 1859384 <1859384@bugs.launchpad.net>\0" - "Cc\0qemu-devel@nongnu.org\0" + "Date\0Mon, 13 Jan 2020 13:44:16 -0000\0" + "To\0qemu-devel@nongnu.org\0" "\00:1\0" "b\0" - "\n" "Alex Longwall <1859384@bugs.launchpad.net> writes:\n" "\n" "> Public bug reported:\n" @@ -219,6 +217,84 @@ "\n" "\n" "-- \n" - "Alex Benn\303\251e" + "Alex Benn\303\251e\n" + "\n" + "-- \n" + "You received this bug notification because you are a member of qemu-\n" + "devel-ml, which is subscribed to QEMU.\n" + "https://bugs.launchpad.net/bugs/1859384\n" + "\n" + "Title:\n" + " arm gic: interrupt model never 1 on non-mpcore and race condition in\n" + " gic_acknowledge_irq\n" + "\n" + "Status in QEMU:\n" + " New\n" + "\n" + "Bug description:\n" + " For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM,\n" + " only one CPU can acknowledge the IRQ until it becomes inactive.\n" + "\n" + " The TRM also mandates that SGIs and PPIs follow the N-N model and that\n" + " SPIs follow the 1-N model.\n" + "\n" + " However this is not currently the case with QEMU. I have locally (no\n" + " minimal test case) seen e.g. uart interrupts being acknowledged twice\n" + " before having been deactivated (expected: irqId on one CPU and 1023 on\n" + " the other instead).\n" + "\n" + " I have narrowed the issue down to the following:\n" + "\n" + " 1) arm_gic_common_reset resets all irq_state[id] fields to 0. This\n" + " means all IRQ will use the N-N model, and if s->revision !=\n" + " REV_11MPCORE, then there's no way to set any interrupt to 1-N.\n" + "\n" + " If \"\"fixed\"\" locally with a hackjob, I still have the following trace:\n" + "\n" + " pl011_irq_state 534130.800 pid=2424 level=0x1\n" + " gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff\n" + " gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1\n" + " gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1\n" + " gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21\n" + " gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1\n" + " gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21\n" + " gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21\n" + " gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21\n" + " pl011_write 1594.700 pid=2424 addr=0x44 value=0x50\n" + " pl011_irq_state 2.000 pid=2424 level=0x0\n" + " gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff\n" + " pl011_write 30.700 pid=2424 addr=0x38 value=0x0\n" + " pl011_irq_state 1.200 pid=2424 level=0x0\n" + " gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21\n" + " gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21\n" + " pl011_irq_state 1169.500 pid=2424 level=0x0\n" + "\n" + " This is because:\n" + "\n" + " 2) gic_acknowledge_irq calls gic_clear_pending which uses\n" + " GIC_DIST_CLEAR_PENDING but this usually has no effect on level-\n" + " sensitive interrupts.\n" + "\n" + " With this often being a no-op (ie. assuming ispendr was not written\n" + " to), any 1-n level-sensitive interrupt is still improperly pending on\n" + " all the other cores.\n" + "\n" + " (Also, I don't really know how the qemu thread model works, there\n" + " might be race conditions in the acknowledgment logic if\n" + " gic_acknowledge_irq is called by multiple threads, too.)\n" + "\n" + " Option used:\n" + " -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu cortex-a57 -smp 4 -m 1024\n" + " -kernel whatever.elf -d unimp,guest_errors -semihosting-config enable,target=native\n" + " -chardev stdio,id=uart -serial chardev:uart -monitor none\n" + " -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state -trace pl011_write -trace gic_cpu_read -trace gic_cpu_write\n" + " -trace gic_set_irq\n" + "\n" + " Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d \"Merge remote-\n" + " tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into\n" + " staging\"\n" + "\n" + "To manage notifications about this bug go to:\n" + https://bugs.launchpad.net/qemu/+bug/1859384/+subscriptions -bef3ccb2ad9307fe77340a30cfb673644467821bfe23a96142e71891b1ff17b2 +dab2724cc3739cc0ba08ec00f0e79fde186da0ac4a1488ab480b986085d6c7b0
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.