From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40357306D3F for ; Wed, 17 Jun 2026 13:03:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781701389; cv=none; b=IqdKWEzKfKecK/UZBASmuvmoU5ZaXzsC5sKQ3WItKkcRGRN7EZxufYaTK/QiIA0G1UuIB6JMqHVRx+Fp7L4uyO121MEtI7eAuprdKQaBzmOaxIP8ZAYemz7xL5CCjUkf7niO3th1+E8qCOzqCLzPjmUcZIcKtFaatPcQVEpM4ig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781701389; c=relaxed/simple; bh=Jgplr6cJMoMN6z/aXhWQHWzsS0EgW53NNDnD4vyPhZY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uGQebemSUtsXQLJz0ZoTBOZX+4qxFVJ3rQ3HH8I6qmYEzrh6VtXyvrIbPeV/3xf2CEx42Co01sqgBh+JyBUHf5sZgOvMVV4LDL5MXP9MwFrqdczjdnzk0BQ3WasUpVILBQm2xjUTswVQfKyTcPeMNuQEY/MoyunsgIweuSXJaWQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=OrNp4eKX; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="OrNp4eKX" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c88939d3a3eso307209a12.3 for ; Wed, 17 Jun 2026 06:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781701388; x=1782306188; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=EM28efTr5yjuE0SO3xRGbNYRHe4cnOYh7jH86+doO9k=; b=OrNp4eKXB9EJsmfg68i1osryWgFoBD/Tfv7QWmir3m1QMoMPjeC/Pc+9vniTvRUVEH 7pHmCOC89T+SW+gk10PFwTn6QZkftpA61lKb74qqBRNpZG1VgAi6VFlqQ6TvyBuyapdJ mVNxWUBcd1xZ2Tdz30j5po2UghDpwOiukRDVouy1OcL6X5N3pGl48HrMdXKXb0c78Zdb ZUn1p3mILN1JMwc6zDQ/5px7Vk5nZLm8qHz0N5sm+XOMxjjTkCUZZocLE4/4IOaxDUng 7Ue+Q7Pu+6qvMvHsLhbMN6q3gFSAwLWKSIokIgG8GzeAlyx7Ffvvu7fPB9VPT+15VIbr SFwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781701388; x=1782306188; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EM28efTr5yjuE0SO3xRGbNYRHe4cnOYh7jH86+doO9k=; b=CSiFJ7guLkW4JIMBruSHWYBtMGTZ9mAJGXXC5cMQY4rEsc2D1yoRJBqfCEgcP5A3M8 4R68jxoH5x9Tbryt+pEickCSnRpZEVv9J2f3z1e2YpYOdLw32g4BoLUYMS6/f7c/xDp6 3Uift38Z3s0qGradjc58cFbZHI6MYX1I9Wqxo5NzHWyVVVSkwfLHzVthF1XL6pLJ3Acc tbXvFjZ1eL+3174/rbPMl7YyUNkpc8H7pIptDMXZLAivt3vuy5mPPsPq8vsgyYHopCEb Q/s2mCige/203X7w9XdtvXCPIQhyJTXpKcOa8ljg3ipFnJZu51bIuCnbjJAkBbCW0gFD tMFg== X-Forwarded-Encrypted: i=1; AFNElJ8vBJZero5dL8dapW4eme2PTgr3LnnfApBckvHQwFk4Se++ZN3/YUYxGdOCDj5C+kMn+Ng6TXYKTPejhZM=@vger.kernel.org X-Gm-Message-State: AOJu0Yyw0b7eilcM3lVpvRuKLzuCXNkKddKPa3N9ZzFe01zad5IA6Pvy 0zchka/0hwAVaCzFuf8R37nokZlnPTjWkjYNjXVKFQy+4+8qJumQgTiTlNz7ZBzr2+MFEk6OXne jHqCObw== X-Received: from pgdg15.prod.google.com ([2002:a05:6a02:51cf:b0:c82:2bb1:fdb0]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:748f:b0:3b2:b1ed:d1df with SMTP id adf61e73a8af0-3b8b72c6650mr4040175637.29.1781701387134; Wed, 17 Jun 2026 06:03:07 -0700 (PDT) Date: Wed, 17 Jun 2026 06:03:06 -0700 In-Reply-To: <5b5a0f3f21bba5d25410382a9e0170a17c952738.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260616214652.2157032-1-yosry@kernel.org> <20260616214652.2157032-2-yosry@kernel.org> <5b5a0f3f21bba5d25410382a9e0170a17c952738.camel@intel.com> Message-ID: Subject: Re: [PATCH 1/3] KVM: nVMX: Always flush vpid02 on first use From: Sean Christopherson To: Kai Huang Cc: "yosry@kernel.org" , "jmattson@google.com" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" On Wed, Jun 17, 2026, Kai Huang wrote: > On Tue, 2026-06-16 at 21:46 +0000, Yosry Ahmed wrote: > > Make sure vpid02 is always flushed on first use by setting last_vpid=0 > > when allocating vpid02. nested_vmx_transition_tlb_flush() will always > > detect a VPID change on first VM-Enter after VMXON, because VPID=0 in > > vmcb12 is not allowed if L1 enables VPID. > > vmcs12 :-) > > > > > This avoids using stale TLB entries from a previous lifetime of the > > VPID, that might have been associated with a different vCPU (or a > > completely different VM). > > > > Note that last_vpid is already being initialized as 0 when the vCPU is > > created, but it is not reset when vpid02 is freed on VMXOFF. Hence, the > > problem can only occur if L1 does VMXOFF -> VMXON, runs an L2, and KVM > > happens to reuse a VPID that has TLB entries on the physical CPU. > > Not sure whether it's better to set it to 0 in free_nested(), which also resets > some other nested fields to clean slate AFAICT? It needs to be set on first use, for the same reason that kvm_mmu_load() flushes the root: /* * Flush any TLB entries for the new root, the provenance of the root * is unknown. Even if KVM ensures there are no stale TLB entries * for a freed root, in theory another hypervisor could have left * stale entries. Flushing on alloc also allows KVM to skip the TLB * flush when freeing a root (see kvm_tdp_mmu_put_root()). */ kvm_x86_call(flush_tlb_current)(vcpu);