diff options
author | Nicholas Piggin <npiggin@gmail.com> | 2022-03-03 15:33:14 +1000 |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2022-05-13 21:34:33 +1000 |
commit | 11681b79b1ab52e7625844d7ce52c4d5201a43b2 (patch) | |
tree | 3fa6cb6cd4914f2e1c3627203bdf97094c9eba6b /mm | |
parent | 42b4a2b347b09e7ee4c86f7121e3b45214b63e69 (diff) | |
download | linux-stable-11681b79b1ab52e7625844d7ce52c4d5201a43b2.tar.gz linux-stable-11681b79b1ab52e7625844d7ce52c4d5201a43b2.tar.bz2 linux-stable-11681b79b1ab52e7625844d7ce52c4d5201a43b2.zip |
KVM: PPC: Book3S HV Nested: L2 must not run with L1 xive context
The PowerNV L0 currently pushes the OS xive context when running a vCPU,
regardless of whether it is running a nested guest. The problem is that
xive OS ring interrupts will be delivered while the L2 is running.
At the moment, by default, the L2 guest runs with LPCR[LPES]=0, which
actually makes external interrupts go to the L0. That causes the L2 to
exit and the interrupt taken or injected into the L1, so in some
respects this behaves like an escalation. It's not clear if this was
deliberate or not, there's no comment about it and the L1 is actually
allowed to clear LPES in the L2, so it's confusing at best.
When the L2 is running, the L1 is essentially in a ceded state with
respect to external interrupts (it can't respond to them directly and
won't get scheduled again absent some additional event). So the natural
way to solve this is when the L0 handles a H_ENTER_NESTED hypercall to
run the L2, have it arm the escalation interrupt and don't push the L1
context while running the L2.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220303053315.1056880-6-npiggin@gmail.com
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions