On Thu, May 29, 2025, Pawan Gupta wrote: > On Thu, May 29, 2025 at 03:19:22PM -0700, Sean Christopherson wrote: > > On Wed, May 28, 2025, Pawan Gupta wrote: > > > On Thu, May 22, 2025 at 06:17:54PM -0700, Sean Christopherson wrote: > > > > @@ -7282,7 +7288,7 @@ static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu, > > > > if (static_branch_unlikely(&vmx_l1d_should_flush)) > > > > vmx_l1d_flush(vcpu); > > > > else if (static_branch_unlikely(&mmio_stale_data_clear) && > > > > - kvm_arch_has_assigned_device(vcpu->kvm)) > > > > + (flags & VMX_RUN_CLEAR_CPU_BUFFERS_FOR_MMIO)) > > > > mds_clear_cpu_buffers(); > > > > > > I think this also paves way for buffer clear for MDS and MMIO to be done at > > > a single place. Please let me know if below is feasible: > > > > It's definitely feasible (this thought crossed my mind as well), but because > > CLEAR_CPU_BUFFERS emits VERW iff X86_FEATURE_CLEAR_CPU_BUF is enabled, the below > > would do nothing for the MMIO case (either that, or I'm missing something). > > Thats right, CLEAR_CPU_BUFFERS needs rework too. > > > We could obviously rework CLEAR_CPU_BUFFERS, I'm just not sure that's worth the > > effort at this point. I'm definitely not opposed to it though. > > My goal with this is to have 2 separate controls for user-kernel and > guest-host. Such that MDS/TAA/RFDS gets finer controls to only enable > user-kernel or guest-host mitigation. This would play well with the Attack > vector series by David: > > https://lore.kernel.org/lkml/20250509162839.3057217-1-david.kaplan@xxxxxxx/ > > For now this patch is fine as is. I will send update separately including > the CLEAR_CPU_BUFFERS rework. Sounds good. Ah, and the s/mmio_stale_data_clear/cpu_buf_vm_clear rename already landed for 6.16-rc1, so we don't have to overthink about the ordering with respect to that change. :-)
