On Wed, Mar 27, 2024 at 05:36:07PM +0000, "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx> wrote: > On Wed, 2024-03-27 at 10:54 +0800, Xiaoyao Li wrote: > > > > If QEMU doesn't configure the msr filter list correctly, KVM has to handle > > > > guest's MTRR MSR accesses. In my understanding, the suggestion is KVM zap > > > > private memory mappings. But guests won't accept memory again because no one > > > > currently requests guests to do this after writes to MTRR MSRs. In this case, > > > > guests may access unaccepted memory, causing infinite EPT violation loop > > > > (assume SEPT_VE_DISABLE is set). This won't impact other guests/workloads on > > > > the host. But I think it would be better if we can avoid wasting CPU resource > > > > on the useless EPT violation loop. > > > > > > Qemu is expected to do it correctly. There are manyways for userspace to go > > > wrong. This isn't specific to MTRR MSR. > > > > This seems incorrect. KVM shouldn't force userspace to filter some > > specific MSRs. The semantic of MSR filter is userspace configures it on > > its own will, not KVM requires to do so. > > I'm ok just always doing the exit to userspace on attempt to use MTRRs in a TD, and not rely on the > MSR list. At least I don't see the problem. KVM doesn't force it. KVM allows QEMU to use the MSR filter for TDX. (v19 doesn't allow it.) If QEMU chooses to use the MSR filter, QEMU has to handle the MSR access correctly. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
