diff options
| author | Lai Jiangshan <laijs@linux.alibaba.com> | 2021-10-19 19:01:52 +0800 | 
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2021-10-22 05:19:30 -0400 | 
| commit | 509bfe3d979672cd69c318d520420cf95b474fd9 (patch) | |
| tree | 07bdaaafcca9436ff1d86bd825ef4f5695c5df71 /lib/mpi/mpi-inv.c | |
| parent | e45e9e3998f0001079b09555db5bb3b4257f6746 (diff) | |
KVM: X86: Cache CR3 in prev_roots when PCID is disabled
The commit 21823fbda5522 ("KVM: x86: Invalidate all PGDs for the
current PCID on MOV CR3 w/ flush") invalidates all PGDs for the specific
PCID and in the case of PCID is disabled, it includes all PGDs in the
prev_roots and the commit made prev_roots totally unused in this case.
Not using prev_roots fixes a problem when CR4.PCIDE is changed 0 -> 1
before the said commit:
	(CR4.PCIDE=0, CR4.PGE=1; CR3=cr3_a; the page for the guest
	 RIP is global; cr3_b is cached in prev_roots)
	modify page tables under cr3_b
		the shadow root of cr3_b is unsync in kvm
	INVPCID single context
		the guest expects the TLB is clean for PCID=0
	change CR4.PCIDE 0 -> 1
	switch to cr3_b with PCID=0,NOFLUSH=1
		No sync in kvm, cr3_b is still unsync in kvm
	jump to the page that was modified in step 1
		shadow page tables point to the wrong page
It is a very unlikely case, but it shows that stale prev_roots can be
a problem after CR4.PCIDE changes from 0 to 1.  However, to fix this
case, the commit disabled caching CR3 in prev_roots altogether when PCID
is disabled.  Not all CPUs have PCID; especially the PCID support
for AMD CPUs is kind of recent.  To restore the prev_roots optimization
for CR4.PCIDE=0, flush the whole MMU (including all prev_roots) when
CR4.PCIDE changes.
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
Message-Id: <20211019110154.4091-3-jiangshanlai@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'lib/mpi/mpi-inv.c')
0 files changed, 0 insertions, 0 deletions
