[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] bede01: hw/arm/virt: Extend nested and mte ch
From: |
Richard Henderson |
Subject: |
[Qemu-commits] [qemu/qemu] bede01: hw/arm/virt: Extend nested and mte checks to hvf |
Date: |
Mon, 29 Nov 2021 04:53:06 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: bede01170e9cb8f9ac9c6a0665ee9f3989a57e6a
https://github.com/qemu/qemu/commit/bede01170e9cb8f9ac9c6a0665ee9f3989a57e6a
Author: Alexander Graf <agraf@csgraf.de>
Date: 2021-11-26 (Fri, 26 Nov 2021)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm/virt: Extend nested and mte checks to hvf
The virt machine has properties to enable MTE and Nested Virtualization
support. However, its check to ensure the backing accel implementation
supports it today only looks for KVM and bails out if it finds it.
Extend the checks to HVF as well as it does not support either today.
This will cause QEMU to print a useful error message rather than
silently ignoring the attempt by the user to enable either MTE or
the Virtualization extensions.
Reported-by: saar amar <saaramar5@gmail.com>
Signed-off-by: Alexander Graf <agraf@csgraf.de>
Message-id: 20211123122859.22452-1-agraf@csgraf.de
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit: 2f459cd1a80d24189598fd3416e270d1feb7dc87
https://github.com/qemu/qemu/commit/2f459cd1a80d24189598fd3416e270d1feb7dc87
Author: Shashi Mallela <shashi.mallela@linaro.org>
Date: 2021-11-26 (Fri, 26 Nov 2021)
Changed paths:
M hw/intc/arm_gicv3_its.c
Log Message:
-----------
hw/intc: cannot clear GICv3 ITS CTLR[Enabled] bit
When Enabled bit is cleared in GITS_CTLR,ITS feature continues
to be enabled.This patch fixes the issue.
Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20211124182246.67691-1-shashi.mallela@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Commit: 101f27f3c834842238624b6c0205be3281883878
https://github.com/qemu/qemu/commit/101f27f3c834842238624b6c0205be3281883878
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2021-11-26 (Fri, 26 Nov 2021)
Changed paths:
M hw/intc/arm_gicv3.c
M hw/intc/arm_gicv3_redist.c
M hw/intc/gicv3_internal.h
Log Message:
-----------
hw/intc/arm_gicv3: Update cached state after LPI state changes
The logic of gicv3_redist_update() is as follows:
* it must be called in any code path that changes the state of
(only) redistributor interrupts
* if it finds a redistributor interrupt that is (now) higher
priority than the previous highest-priority pending interrupt,
then this must be the new highest-priority pending interrupt
* if it does *not* find a better redistributor interrupt, then:
- if the previous state was "no interrupts pending" then
the new state is still "no interrupts pending"
- if the previous best interrupt was not a redistributor
interrupt then that remains the best interrupt
- if the previous best interrupt *was* a redistributor interrupt,
then the new best interrupt must be some non-redistributor
interrupt, but we don't know which so must do a full scan
In commit 17fb5e36aabd4b2c125 we effectively added the LPI interrupts
as a kind of "redistributor interrupt" for this purpose, by adding
cs->hpplpi to the set of things that gicv3_redist_update() considers
before it gives up and decides to do a full scan of distributor
interrupts. However we didn't quite get this right:
* the condition check for "was the previous best interrupt a
redistributor interrupt" must be updated to include LPIs
in what it considers to be redistributor interrupts
* every code path which updates the LPI state which
gicv3_redist_update() checks must also call gicv3_redist_update():
this is cs->hpplpi and the GICR_CTLR ENABLE_LPIS bit
This commit fixes this by:
* correcting the test on cs->hppi.irq in gicv3_redist_update()
* making gicv3_redist_update_lpi() always call gicv3_redist_update()
* introducing a new gicv3_redist_update_lpi_only() for the one
callsite (the post-load hook) which must not call
gicv3_redist_update()
* making gicv3_redist_lpi_pending() always call gicv3_redist_update(),
either directly or via gicv3_redist_update_lpi()
* removing a couple of now-unnecessary calls to gicv3_redist_update()
from some callers of those two functions
* calling gicv3_redist_update() when the GICR_CTLR ENABLE_LPIS
bit is cleared
(This means that the not-file-local gicv3_redist_* LPI related
functions now all take care of the updates of internally cached
GICv3 information, in the same way the older functions
gicv3_redist_set_irq() and gicv3_redist_send_sgi() do.)
The visible effect of this bug was that when the guest acknowledged
an LPI by reading ICC_IAR1_EL1, we marked it as not pending in the
LPI data structure but still left it in cs->hppi so we would offer it
to the guest again. In particular for setups using an emulated GICv3
and ITS and using devices which use LPIs (ie PCI devices) a Linux
guest would complain "irq 54: nobody cared" and then hang. (The hang
was intermittent, presumably depending on the timing between
different interrupts arriving and being completed.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20211124202005.989935-1-peter.maydell@linaro.org
Commit: b74d7c0e50ac4bde85c0ff629bfc23cdf378e62c
https://github.com/qemu/qemu/commit/b74d7c0e50ac4bde85c0ff629bfc23cdf378e62c
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2021-11-26 (Fri, 26 Nov 2021)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
M hw/intc/gicv3_internal.h
Log Message:
-----------
hw/intc/arm_gicv3: Add new gicv3_intid_is_special() function
The GICv3/v4 pseudocode has a function IsSpecial() which returns true
if passed a "special" interrupt ID number (anything between 1020 and
1023 inclusive). We open-code this condition in a couple of places,
so abstract it out into a new function gicv3_intid_is_special().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Commit: 90feffad2aafe856ed2af75313b2c1669ba671e9
https://github.com/qemu/qemu/commit/90feffad2aafe856ed2af75313b2c1669ba671e9
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2021-11-29 (Mon, 29 Nov 2021)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
Log Message:
-----------
hw/intc/arm_gicv3: fix handling of LPIs in list registers
It is valid for an OS to put virtual interrupt ID values into the
list registers ICH_LR<n> which are greater than 1023. This
corresponds to (for example) KVM using the in-kernel emulated ITS to
give a (nested) guest an ITS. LPIs are delivered by the L1 kernel to
the L2 guest via the list registers in the same way as non-LPI
interrupts.
QEMU's code for handling writes to ICV_IARn (which happen when the L2
guest acknowledges an interrupt) and to ICV_EOIRn (which happen at
the end of the interrupt) did not consider LPIs, so it would
incorrectly treat interrupt IDs above 1023 as invalid. Fix this by
using the correct condition, which is gicv3_intid_is_special().
Note that the condition in icv_dir_write() is correct -- LPIs
are not valid there and so we want to ignore both "special" ID
values and LPIs.
(In the pseudocode this logic is in:
- VirtualReadIAR0(), VirtualReadIAR1(), which call IsSpecial()
- VirtualWriteEOIR0(), VirtualWriteEOIR1(), which call
VirtualIdentifierValid(data, TRUE) meaning "LPIs OK"
- VirtualWriteDIR(), which calls VirtualIdentifierValid(data, FALSE)
meaning "LPIs not OK")
This bug doesn't seem to have any visible effect on Linux L2 guests
most of the time, because the two bugs cancel each other out: we
neither mark the interrupt active nor deactivate it. However it does
mean that the L2 vCPU priority while the LPI handler is running will
not be correct, so the interrupt handler could be unexpectedly
interrupted by a different interrupt.
(NB: this has nothing to do with using QEMU's emulated ITS.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Commit: e750c10167fa8ad3fcc98236a474c46e52e7c18c
https://github.com/qemu/qemu/commit/e750c10167fa8ad3fcc98236a474c46e52e7c18c
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-11-29 (Mon, 29 Nov 2021)
Changed paths:
M hw/arm/virt.c
M hw/intc/arm_gicv3.c
M hw/intc/arm_gicv3_cpuif.c
M hw/intc/arm_gicv3_its.c
M hw/intc/arm_gicv3_redist.c
M hw/intc/gicv3_internal.h
Log Message:
-----------
Merge tag 'pull-target-arm-20211129' of
https://git.linaro.org/people/pmaydell/qemu-arm into staging
target-arm queue:
* virt: Diagnose attempts to enable MTE or virt when using HVF accelerator
* GICv3 ITS: Allow clearing of ITS CTLR Enabled bit
* GICv3: Update cached state after LPI state changes
* GICv3: Fix handling of LPIs in list registers
# gpg: Signature made Mon 29 Nov 2021 11:34:46 AM CET
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
[full]
* tag 'pull-target-arm-20211129' of
https://git.linaro.org/people/pmaydell/qemu-arm:
hw/intc/arm_gicv3: fix handling of LPIs in list registers
hw/intc/arm_gicv3: Add new gicv3_intid_is_special() function
hw/intc/arm_gicv3: Update cached state after LPI state changes
hw/intc: cannot clear GICv3 ITS CTLR[Enabled] bit
hw/arm/virt: Extend nested and mte checks to hvf
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Compare: https://github.com/qemu/qemu/compare/dd4b0de45965...e750c10167fa
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] bede01: hw/arm/virt: Extend nested and mte checks to hvf,
Richard Henderson <=