On Wed, Mar 16, 2022 at 06:17:29AM +0800, Paolo Bonzini wrote: > MSR filtering requires an exit to userspace that is hard to implement and > would be very slow in the case of nested VMX vmexit and vmentry MSR > accesses. Document the limitation. > > Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > --- > Documentation/virt/kvm/api.rst | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 0e08253b003f..8911a4310406 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4091,6 +4091,11 @@ x2APIC MSRs are always allowed, independent of the ``default_allow`` setting, > and their behavior depends on the ``X2APIC_ENABLE`` bit of the APIC base > register. > > +.. warning:: > + MSR accesses coming from nested vmentry/vmexit are not filtered. > + This includes both writes to individual VMCS fields and reads/writes > + through the MSR lists pointed to by the VMCS. > + Should we document that only MSR accesses coming from rdmsr/wrmsr are filtered? Other instructions like RDPID/RDTSCP can also do MSR access, but can't be filtered by msr bitmap. > If a bit is within one of the defined ranges, read and write accesses are > guarded by the bitmap's value for the MSR index if the kind of access > is included in the ``struct kvm_msr_filter_range`` flags. If no range > -- > 2.31.1