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 614C334DB41 for ; Mon, 23 Feb 2026 08:55:52 +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=1771836953; cv=none; b=hu+vU394aE6kMPggtC++f0vB6TImuBhggp2tWB+p5eq13cutOoVjhG7Kfhwvh00veXKnpCF0wsAKyR2mHb+ijm6if+g6Hpcj3m3WeJx7Zf2INmokufIj3odo+zCazMQkXX7ISz5ghrTtPCpeTO/4iQKDEAtzG7zqFzpBZbzNa/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771836953; c=relaxed/simple; bh=KYFlfC8sXrxlylue5TpXssTcOuehH7BERDSDVQq92dw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Ma4oNcuzII2dC/AZNDRGcq1DiF41WOnvxCbq0P+zHdhHE9YTYLLEOLlmlWgaiK1TP1u69R+SjjWSpsMr0ZMglVJlOP04VCxZO9/1bpMrf/sW1htVE1MSWMYXEaRgTKCAC7OhlZpJihnwMErJFFMjiVke/7ekOitgWTOGqmjud74= 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=DZk96Dan; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=WqJTvPst; 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="DZk96Dan"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="WqJTvPst" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771836951; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HlfPtuoIVP7zNl5EzRr0slKeeyrKnAzFG3uyLdGjiYo=; b=DZk96DanGBvtWRK+OKWUXOQ/CCoVbWAjag3KhFtF8LQSMfAuCfOa4ifFVLP9en/3p6MYSy qNBg5G0JqAf7R9IX8EDJNrvgcp9bLzJxG+jhxEAAFKaVm6+NW4Kr3WP4SuriN7MYQiOdoG ysJMg07lu22sKJI0Nc4Y1dNTWSSCtRY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-269-75IA8Rh_Pmu-8OmyyohzaA-1; Mon, 23 Feb 2026 03:55:49 -0500 X-MC-Unique: 75IA8Rh_Pmu-8OmyyohzaA-1 X-Mimecast-MFC-AGG-ID: 75IA8Rh_Pmu-8OmyyohzaA_1771836949 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-48071615686so39775975e9.1 for ; Mon, 23 Feb 2026 00:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1771836949; x=1772441749; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=HlfPtuoIVP7zNl5EzRr0slKeeyrKnAzFG3uyLdGjiYo=; b=WqJTvPstOAsmsURzTxsrFNVrNCNCpBQBE5tOnt+IiRfJt2MuadzlrQPYFsg5ZpurSB 9dr/AWY3OsptDDVj0o9VLmxBpZwNHO43S7xP1BSK1nr5Kt65CVg4Df3CCbQN1/+iR5RY 2eYkgsmSGT9tfYjarHB/SM4G+sZgPxNT6DzJ0GBi7BZX6KZ3NHoaMPgM+3MCHRuCY0c2 83GPd1+Bbp+7JhwKrcT44CB4ZUyjf6yd1OdGSJLzBm38NI/2GrRdGYMNZx9icswf3K2G WlmGQA4x7dKPyOocR41Nb/wLf8VrNLkHFG42/KgQtt/2MQtvRK1e9EjDdv5x/y6Z0W/X vkdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771836949; x=1772441749; h=content-transfer-encoding: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=HlfPtuoIVP7zNl5EzRr0slKeeyrKnAzFG3uyLdGjiYo=; b=kY5koHJuVj/4hIw5ED9ilnT6MqbILXSbCl7IFJ8H9/JdVYP/4diMYxnsyUreWwgAoL z6vgZWA9yn3yXAFO9edz+E+6fLqHUreaH87s/OaSPqSA5lfxU9tQWDJ5c5Pc5FsjJBp5 nnopeko+skoVZJCOjDbRp2A58ZqObxRYBpmo85wpXRh9NJRk7+PAMSuI2kbF2+Jmb7ll TO98tSqL5yBGsB3TshBTWxsxxbuXGOj774HTuXElW7r0b4C1E7HFhTukRFUZTncPzXcf GMu/AXmAWjPt0xrxCNoQLdAZkUKhz0O484vxe9UeyhQSZNankoW7ghkFm37dDt73qzRK Ebdg== X-Forwarded-Encrypted: i=1; AJvYcCWfcU1fufpouaM8VCCDeNdMEZkTxM4IRBcmo+ScRNqqQTlVnLUXXRMsRweLJqUMKQqze+7pOsnH6PsMx7I=@vger.kernel.org X-Gm-Message-State: AOJu0YxT7RQMM/hyp5HMWTOusfLeB+iDP94WOVoEal7Z5mlf1bw3vDwB eecYKB0Sj87qk50Vk9XRxVOGBP2LPbRLgKKCVOD03UYB8C7JsBlCNBrfgdwaiH3qPhIbZ6fDu75 W7lRGnS7YqnhhSeIdYaxozXCPSLsLRT/CoUsZh0Cs8Hl6Nt8cb77fy2I0oWlymZ/O/g== X-Gm-Gg: AZuq6aIoiphr8aKFfMPK+vWmUtjNMsSC3cuOXJC2FTlyD+M/B5Kpvrb4erdWvpUf5Cw bVMrSeZseHAKcy+wsPqegY6lRuWZb4qBASGzqTyPH2RFXv8OokAjO03cdlJl41dY4KbMOFoVKG7 ez5fAuBIb0G5JWfC1RNYsNrxvON74pnsr5EGm4k3iOPiGdC70kb50KttV4Vur5NQ92nMDMsC2BB 16MaPpfC4Iuwlg+pDLskblyVCriq6hTJWNfSGCATc0DAV+ZF1WHvSu67qKvaKdzxmaH7TN84Igy lVZtgkTypsa6HSTWDretTV2z8Gy8Sdexd5WmhYe91tNqPymv5bOTbGjqNpmOfD6LcorBf6J5sxe q+0ZUt16Y/tRh0n9tMQ== X-Received: by 2002:a05:600c:5394:b0:483:6a8d:b2fc with SMTP id 5b1f17b1804b1-483a95b7162mr109762325e9.8.1771836948630; Mon, 23 Feb 2026 00:55:48 -0800 (PST) X-Received: by 2002:a05:600c:5394:b0:483:6a8d:b2fc with SMTP id 5b1f17b1804b1-483a95b7162mr109762035e9.8.1771836948063; Mon, 23 Feb 2026 00:55:48 -0800 (PST) Received: from fedora (g3.ign.cz. [91.219.240.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483a4424106sm193187565e9.0.2026.02.23.00.55.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Feb 2026 00:55:47 -0800 (PST) From: Vitaly Kuznetsov To: Sean Christopherson , Manuel Andreas Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini Subject: Re: [PATCH] x86/hyper-v: Validate entire GVA range for non-canonical addresses during PV TLB flush In-Reply-To: References: <00a7a31b-573b-4d92-91f8-7d7e2f88ea48@tum.de> Date: Mon, 23 Feb 2026 09:55:46 +0100 Message-ID: <87pl5vu9d9.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sean Christopherson writes: > +Vitaly and Paolo > > Please use scripts/get_maintainer.pl, otherwise your emails might not rea= ch the > right eyeballs. > > On Thu, Feb 19, 2026, Manuel Andreas wrote: >> In KVM guests with Hyper-V hypercalls enabled, the hypercalls >> HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_= EX >> allow a guest to request invalidation of portions of a virtual TLB. >> For this, the hypercall parameter includes a list of GVAs that are suppo= sed >> to be invalidated. >>=20 >> Currently, only the base GVA is checked to be canonical. In reality, >> this check needs to be performed for the entire range of GVAs. >> This still enables guests running on Intel hardware to trigger a >> WARN_ONCE in the host (see prior commit below). >>=20 >> This patch simply moves the check for non-canonical addresses to be >> performed for every single GVA of the supplied range. This should also >> be more in line with the Hyper-V specification, since, although >> unlikely, a range starting with an invalid GVA may still contain >> GVAs that are valid. >>=20 >> Fixes: fa787ac07b3c ("KVM: x86/hyper-v: Skip non-canonical addresses dur= ing PV TLB flush") >> Signed-off-by: Manuel Andreas >> --- >> arch/x86/kvm/hyperv.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >>=20 >> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> index de92292eb1f5..f4f6accf1a33 100644 >> --- a/arch/x86/kvm/hyperv.c >> +++ b/arch/x86/kvm/hyperv.c >> @@ -1981,16 +1981,17 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu) >> if (entries[i] =3D=3D KVM_HV_TLB_FLUSHALL_ENTRY) >> goto out_flush_all; >>=20=20 >> - if (is_noncanonical_invlpg_address(entries[i], vcpu)) >> - continue; >> - >> /* >> * Lower 12 bits of 'address' encode the number of additional >> * pages to flush. >> */ >> gva =3D entries[i] & PAGE_MASK; >> - for (j =3D 0; j < (entries[i] & ~PAGE_MASK) + 1; j++) >> + for (j =3D 0; j < (entries[i] & ~PAGE_MASK) + 1; j++) { >> + if (is_noncanonical_invlpg_address(gva + j * PAGE_SIZE, vcpu)) >> + continue; >> + >> kvm_x86_call(flush_tlb_gva)(vcpu, gva + j * PAGE_SIZE); >> + } > > Vitaly, can we treat the entire request as garbage and throw it away if a= ny part > isn't valid? Or do you think we should go with the more conservative app= roach > as above? I don't remember if I have ever seen real Windows trying to flush anything non-canonical at all but my gut feeling tells me we should rather play safe and use Manuel's 'conservative' approach. Also, this should be consistent with TLFS which says: "Invalid GVAs (those that specify addresses beyond the end of the partition=E2=80=99s GVA space) are ignored." i.e. it doesn't say 'Invalid GVA RANGES are ignored'. > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index de92292eb1f5..f568f3d4f6e5 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -1967,8 +1967,8 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu) > struct kvm_vcpu_hv_tlb_flush_fifo *tlb_flush_fifo; > struct kvm_vcpu_hv *hv_vcpu =3D to_hv_vcpu(vcpu); > u64 entries[KVM_HV_TLB_FLUSH_FIFO_SIZE]; > + gva_t gva, extra_pages; > int i, j, count; > - gva_t gva; >=20=20 > if (!tdp_enabled || !hv_vcpu) > return -EINVAL; > @@ -1978,18 +1978,22 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu *vcpu) > count =3D kfifo_out(&tlb_flush_fifo->entries, entries, KVM_HV_TLB= _FLUSH_FIFO_SIZE); >=20=20 > for (i =3D 0; i < count; i++) { > + > if (entries[i] =3D=3D KVM_HV_TLB_FLUSHALL_ENTRY) > goto out_flush_all; >=20=20 > - if (is_noncanonical_invlpg_address(entries[i], vcpu)) > - continue; > - > /* > * Lower 12 bits of 'address' encode the number of additi= onal > * pages to flush. > */ > gva =3D entries[i] & PAGE_MASK; > - for (j =3D 0; j < (entries[i] & ~PAGE_MASK) + 1; j++) > + extra_pages =3D (entries[i] & ~PAGE_MASK); > + > + if (is_noncanonical_invlpg_address(gva, vcpu) || > + is_noncanonical_invlpg_address(gva + extra_pages * PA= GE_SIZE)) > + continue; > + > + for (j =3D 0; j < extra_pages + 1; j++) > kvm_x86_call(flush_tlb_gva)(vcpu, gva + j * PAGE_= SIZE); >=20=20 > ++vcpu->stat.tlb_flush; > --=20 Vitaly