From: Lai Jiangshan <laijs(a)linux.alibaba.com>
[ Upstream commit e45e9e3998f0001079b09555db5bb3b4257f6746 ]
The KVM doesn't know whether any TLB for a specific pcid is cached in
the CPU when tdp is enabled. So it is better to flush all the guest
TLB when invalidating any single PCID context.
The case is very rare or even impossible since KVM generally doesn't
intercept CR3 write or INVPCID instructions when tdp is enabled, so the
fix is mostly for the sake of overall robustness.
Signed-off-by: Lai Jiangshan <laijs(a)linux.alibaba.com>
Message-Id: <20211019110154.4091-2-jiangshanlai(a)gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/x86/kvm/x86.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c48e2b5729c5d..0644f429f848c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1091,6 +1091,18 @@ static void kvm_invalidate_pcid(struct kvm_vcpu *vcpu, unsigned long pcid)
unsigned long roots_to_free = 0;
int i;
+ /*
+ * MOV CR3 and INVPCID are usually not intercepted when using TDP, but
+ * this is reachable when running EPT=1 and unrestricted_guest=0, and
+ * also via the emulator. KVM's TDP page tables are not in the scope of
+ * the invalidation, but the guest's TLB entries need to be flushed as
+ * the CPU may have cached entries in its TLB for the target PCID.
+ */
+ if (unlikely(tdp_enabled)) {
+ kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
+ return;
+ }
+
/*
* If neither the current CR3 nor any of the prev_roots use the given
* PCID, then nothing needs to be done here because a resync will
--
2.33.0
It looks like the current work in progress branch for 5.15.5-rc1
picked up fe1bda72c1e8 "ASoC: SOF: Intel: hda-dai: fix potential
locking issue" without also picking 868ddfcef31f "ALSA: hda:
hdac_ext_stream: fix potential locking issues" from master. This
causes builds to fail on x86_64 using clang:
...
CC [M] drivers/misc/eeprom/at25.o
CC [M] drivers/block/pktcdvd.o
LTO [M] sound/soc/codecs/snd-soc-max98088.lto.o
sound/soc/sof/intel/hda-dai.c:111:4: error: implicit declaration of
function 'snd_hdac_ext_stream_decouple_locked'
[-Werror,-Wimplicit-function-declaration]
snd_hdac_ext_stream_decouple_locked(bus, res, true);
^
sound/soc/sof/intel/hda-dai.c:111:4: note: did you mean
'snd_hdac_ext_stream_decouple'?
./include/sound/hdaudio_ext.h:91:6: note:
'snd_hdac_ext_stream_decouple' declared here
void snd_hdac_ext_stream_decouple(struct hdac_bus *bus,
^
1 error generated.
make[4]: *** [scripts/Makefile.build:277: sound/soc/sof/intel/hda-dai.o] Error 1
make[3]: *** [scripts/Makefile.build:540: sound/soc/sof/intel] Error 2
make[2]: *** [scripts/Makefile.build:540: sound/soc/sof] Error 2
make[2]: *** Waiting for unfinished jobs....
AR drivers/misc/cb710/built-in.a
CC [M] drivers/misc/cb710/core.o
CC [M] net/netfilter/xt_nfacct.o
...
After cherry-picking the second commit (868ddfcef31f) builds complete normally.
In case it's relevant there's a third commit in this same series
that's also not included: 1465d06a6d85, "ALSA: hda: hdac_stream: fix
potential locking issue in snd_hdac_stream_assign()".
Scott