From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 093DC39150A for ; Wed, 4 Mar 2026 08:36:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772613400; cv=none; b=LH6i5W1KSUNelwcsosB98V4SCOL/TE0/YmqH5STA3T4uIH9pWzt8qm5qC7p5s9j2L98Te5T3Obn61yqvnKYOrXzQSrOdmvyvkm8bwa5TNaAtNk5HRwZPNSt9w77xAA6Ep9uAM29nEffDJzime+u7G/vastuF/6CKqvXrm+Ve9sU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772613400; c=relaxed/simple; bh=QSBcGmDsWK/NH6et+dG1iPnSDXX0/3NVX+QCWh2smAo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MqE3/XLu04jF39Pdn+uze/TsX59HlXnLfBz/Lx45tPzfcA93sYDDy3c39R5iotL0NgqH4huPWX5ztq79/giw8ZgIq/gUdtKLOJdQJSH3Qpi21xvcfFpdhUcwJCfiqdzWuKUEkeTS3loo/5GPFe6aL4u1hGJgf3E2ExVTpEhDB4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=afHC+Kmu; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ORVptZ4B; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="afHC+Kmu"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ORVptZ4B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772613398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uwX6iKeeaH2J9b02p03XpBrgDxfB3A6QtMrwxI6mtEQ=; b=afHC+KmucQGsjdg+lUBzGRXcDpJX/gfjFJaR9AT46bqUVC16jngLdaHz+jEkvHxhVoPxse QmVvolASFkymySJ4Yy8X/vXSgf1l+v3Xh+mdV5SeN++7hyH8uISOwF6XjrRu6lHLMm8Nhy BVCLtEavVIhsCeYAday0eXqQiqTJgYs= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-593-s5IVmt0qMq6Rm-OfmcC09A-1; Wed, 04 Mar 2026 03:36:36 -0500 X-MC-Unique: s5IVmt0qMq6Rm-OfmcC09A-1 X-Mimecast-MFC-AGG-ID: s5IVmt0qMq6Rm-OfmcC09A_1772613395 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-4836abfc742so51161245e9.0 for ; Wed, 04 Mar 2026 00:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772613395; x=1773218195; darn=vger.kernel.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=uwX6iKeeaH2J9b02p03XpBrgDxfB3A6QtMrwxI6mtEQ=; b=ORVptZ4Bum/UPCcdvcLiHFa2u53+HXxmYPr8zzN590Ru/8BXW2qTP2CZJWLpv0kyDm 8hz58nqLKBjpEoJ0jwcCR3E4haiLv3kjh7RYB+17fixklIGdKXhfnaTqzFZqsgI+C2QB XWjo2bRueMrDngPvB2oWQ3sA/ZYEWwc3mTK9b15jzQuvqvRHTOE2uZuaQpkshOf+t+MC 0/5NdInbaRkEhAwX2t7TvVVGLozP2QZX5j3evcUeA3stO3R3wj8f0jhtUyR2mMngaIXD vj4LkZzrKdf41rUp3v09Nl6YvxCZcaw977sufB8Mj33mJEZpulKWirskJRe9lmnK7N2Q uxCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772613395; x=1773218195; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uwX6iKeeaH2J9b02p03XpBrgDxfB3A6QtMrwxI6mtEQ=; b=QvlVkUif8Fv1cNv89CDJxBDCmB4GyTsgwDjuXIcvVwYhdSatSk2ojcFBdwnNE8OYus X9IPzeOwCZ86pZtuTYsr6e91X3sgl7ygeMtAzSu2Ye3cpNpUl2Pdd+Qcmy3qk2PUtL56 AtJLrVSA89dpdUrjfVY0u1+LbzlV6IOjE/jtHVi5UVsOa1hSnnwcZxaUBHTwVFH6XgPL k4gFQZGrmVl7C3PRUaxhnKdS5kCPdX3rULOh7ehoFfXfrdMNlv/ne73herv39L0EGyR2 xg+gdl/31w2Vr8mxLtGWwIsHi8SsOnng8PapPpb1h0wL3g1RnlxqHbXzsGnkVZu0FJHj Ca1A== X-Forwarded-Encrypted: i=1; AJvYcCVlU9PwqoNs5MiUbnW01IKTZFGeqmmVlBC/wM+v/arvK9st9xZTlsmDkErYzwwrkC66qC6LqVfg7LedwzM=@vger.kernel.org X-Gm-Message-State: AOJu0YxKUvlqA/YrOVafgEgiJ0TC6VpPuVz63tD7yJbUcUMfytecMXkW MJ4XHG9Kvk1R8pSG72cvB4lQHHurlj9uzAz7BVOZ10XlJLJiXEtq1kEnKdFCe6XYnGb/CYnK1He wee0plAIs+VUAGFPW5bCEJHX7L8VzoFqoF7Q+4KSVpP6+/NFsnY2D/DO7IhlS5ElT6g== X-Gm-Gg: ATEYQzxb9IG3uUo/O1YNpHB0XmyWwi9szWGxQeGHAFD+4B6Wzm+W4Zz9EsidmRSvwLb 8dMHBd/xtutPivOppoPNlpWPlpXhFE63zWfmhGgVMpYcHGl8D0yTGKIYDAida+D5/06KWClhMRX +ZPGq6/HkANZwvandKpPdiVG7BtcGrhOO0ar+XBsfqqtVY/2Q20bISolIq0mP/7YU7mJFkH3WNJ 4uWNxJgQUTgyBNVhkXaTrIk7F908gdGbczKNxSG3izPqDjZeGT1CoGASqBnYbSm4n9VMTeGVwUe +hVa+7nI1LBedhdNQXgI3ReBhFJE0xzwSl5z3hQtFox/Cy9FZjf63IQlFpL6vvLn6WY8nlznCon X2GwemF1zMl2PBhxzVg== X-Received: by 2002:a05:600c:a15:b0:47e:e779:36d with SMTP id 5b1f17b1804b1-48519881d19mr19104905e9.23.1772613395385; Wed, 04 Mar 2026 00:36:35 -0800 (PST) X-Received: by 2002:a05:600c:a15:b0:47e:e779:36d with SMTP id 5b1f17b1804b1-48519881d19mr19104545e9.23.1772613394929; Wed, 04 Mar 2026 00:36:34 -0800 (PST) Received: from fedora (g3.ign.cz. [91.219.240.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485187caf9fsm40447835e9.7.2026.03.04.00.36.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 00:36:34 -0800 (PST) From: Vitaly Kuznetsov To: Sean Christopherson , Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Kevin Cheng Subject: Re: [PATCH v5 2/2] KVM: nSVM: Always intercept VMMCALL when L2 is active In-Reply-To: <20260304002223.1105129-3-seanjc@google.com> References: <20260304002223.1105129-1-seanjc@google.com> <20260304002223.1105129-3-seanjc@google.com> Date: Wed, 04 Mar 2026 09:36:33 +0100 Message-ID: <878qc8f0tq.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Sean Christopherson writes: > Always intercept VMMCALL now that KVM properly synthesizes a #UD as > appropriate, i.e. when L1 doesn't want to intercept VMMCALL, to avoid > putting L2 into an infinite #UD loop if KVM_X86_QUIRK_FIX_HYPERCALL_INSN > is enabled. > > By letting L2 execute VMMCALL natively and thus #UD, for all intents and > purposes KVM morphs the VMMCALL intercept into a #UD intercept (KVM always > intercepts #UD). When the hypercall quirk is enabled, KVM "emulates" > VMMCALL in response to the #UD by trying to fixup the opcode to the "right" > vendor, then restarts the guest, without skipping the VMMCALL. As a > result, the guest sees an endless stream of #UDs since it's already > executing the correct vendor hypercall instruction, i.e. the emulator > doesn't anticipate that the #UD could be due to lack of interception, as > opposed to a truly undefined opcode. > > Fixes: 0d945bd93511 ("KVM: SVM: Don't allow nested guest to VMMCALL into host") > Cc: stable@vger.kernel.org > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/svm/hyperv.h | 4 ---- > arch/x86/kvm/svm/nested.c | 7 ------- > 2 files changed, 11 deletions(-) > > diff --git a/arch/x86/kvm/svm/hyperv.h b/arch/x86/kvm/svm/hyperv.h > index 9af03970d40c..f70d076911a6 100644 > --- a/arch/x86/kvm/svm/hyperv.h > +++ b/arch/x86/kvm/svm/hyperv.h > @@ -51,10 +51,6 @@ static inline bool nested_svm_is_l2_tlb_flush_hcall(struct kvm_vcpu *vcpu) > void svm_hv_inject_synthetic_vmexit_post_tlb_flush(struct kvm_vcpu *vcpu); > #else /* CONFIG_KVM_HYPERV */ > static inline void nested_svm_hv_update_vm_vp_ids(struct kvm_vcpu *vcpu) {} > -static inline bool nested_svm_l2_tlb_flush_enabled(struct kvm_vcpu *vcpu) > -{ > - return false; > -} > static inline bool nested_svm_is_l2_tlb_flush_hcall(struct kvm_vcpu *vcpu) > { > return false; > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c > index 750bf93c5341..2ac28d2c34ca 100644 > --- a/arch/x86/kvm/svm/nested.c > +++ b/arch/x86/kvm/svm/nested.c > @@ -156,13 +156,6 @@ void recalc_intercepts(struct vcpu_svm *svm) > vmcb_clr_intercept(c, INTERCEPT_VINTR); > } > > - /* > - * We want to see VMMCALLs from a nested guest only when Hyper-V L2 TLB > - * flush feature is enabled. > - */ > - if (!nested_svm_l2_tlb_flush_enabled(&svm->vcpu)) > - vmcb_clr_intercept(c, INTERCEPT_VMMCALL); > - > for (i = 0; i < MAX_INTERCEPT; i++) > c->intercepts[i] |= g->intercepts[i]; Reviewed-by: Vitaly Kuznetsov -- Vitaly