diff for duplicates of <87k15vo4i7.fsf@linaro.org>
diff --git a/a/1.txt b/N1/1.txt
index 1a6c225..9f15a1b 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,3 @@
-
Alex Longwall <1859384@bugs.launchpad.net> writes:
> Public bug reported:
@@ -211,4 +210,82 @@ applies to all mmio emulated devices.
--
-Alex Bennée
\ No newline at end of file
+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
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 0b2b570..c994f0f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -8,13 +8,10 @@
"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"
+ "Date\0Mon, 13 Jan 2020 13:44:16 -0000\0"
]
[
- "To\0Bug 1859384 <1859384\@bugs.launchpad.net>\0"
-]
-[
- "Cc\0qemu-devel\@nongnu.org\0"
+ "To\0qemu-devel\@nongnu.org\0"
]
[
"\0000:1\0"
@@ -23,7 +20,6 @@
"b\0"
]
[
- "\n",
"Alex Longwall <1859384\@bugs.launchpad.net> writes:\n",
"\n",
"> Public bug reported:\n",
@@ -236,7 +232,85 @@
"\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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).