From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.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 F3D58286A4 for ; Fri, 6 Mar 2026 15:54:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772812471; cv=none; b=RglGvD5c16me1lDnCMnq7jPSdQLq3pEchmx8FK+tSfldjNPLtVbWEnL4F4uAuUUPUiW84a4kNU+Bq63EJhwRUtTuYw63B48miU6gIXzXeI2kjr8N80TavAL62yY+sDg1UwleUpeOgyrNu5OejLdD6c4zwKpHdoa6wtaghjv48HU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772812471; c=relaxed/simple; bh=DCdYafJ1q85ldEBfRTNqL/Y3XaF2wiN51HteaKHK1yo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uWR4kpJfZgy5iPkX80sqCdG9o5Uv3N2BS6fLqEEQWIWJScxJBuw5l7kjAjAQenQ4uyS3mCsxH5uDtFz5asbK/qqbkJff/s4285niiqJ0AyRoz2Fw1FEbiVKqPejLf7A0jBd0AA5/QJkfeKPnhHzoqAF2awmVujymlfWqDDXDFm0= 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=kS9SQa4o; arc=none smtp.client-ip=209.85.210.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="kS9SQa4o" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-82990cfa91aso672026b3a.1 for ; Fri, 06 Mar 2026 07:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772812469; x=1773417269; 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=/X89hp+5U+/q1xbg5uksPepQg6bue5vmq9BCayk/Rl4=; b=kS9SQa4o10cSJ2+NsKla5FLvy1bxQNCsx70vkV8CEU0wNnbpDNa8912g/x6MVME/TV GvL1qHmPaUSnx8FYiHymJJ/di/Mt8wScksgj/mv9IvYrxExH3r/GFgE0MPW9KBDLVCI6 7KUOFV872krAkndgS1Qf5GkWOF86fEQH9B5q08TEBuNdbb6M8GRKFetJ9fiGohIvHA0g h4comjQGPbCuu8s6GtHpFjbjNoeP4QyM+pvCtxA7bBvIoizkxTNz+v7MCbIlt9pfzIJa yh0Mt24fw4SX2qkyynKR6gNc0oyETdIIBwybnvyb/Dt2kqVoDfDbmPa5Ga2tB7DkIt9U 7ejw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772812469; x=1773417269; 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=/X89hp+5U+/q1xbg5uksPepQg6bue5vmq9BCayk/Rl4=; b=jmrNpZsy3USTtGzlCCIMfX4Qh74C7W2BvrDwaRVvDAtSIj0XpwMFTz7xd+ZKHb0hJY dV1jUeJ3AXnihWMt2IK5XGmOkQgSicA6zKAQXyAw7ie5y9jFlTP+w0TcJr9bfH69kmMG fFeyhNLA7R8edMOqiXkbuvkkZ7hG3cABj0mVHKti7FtoYBUaa7j7GEGE4cJiqh/s76hI UrUW6w+8hl+mLurPnIu1xAk/pjXYGAEx0bJxTZK6tYYkruYL0G5/1ODmmgxwGg98Ulag vk3+I9oSLAc7H6cIFT6zj4r9sMk/cBEatdLnJ0sLEfFp7TMkX+6g5Xt0IoPymE77Yzl1 sGjQ== X-Forwarded-Encrypted: i=1; AJvYcCVG6zU863NVq2Ycro69bkX5hoC0I5dIRE3yecGL1KpXHiVEcW7fFJyM00uZs6tzp+PGlmxAHvDBxMGdGTY=@vger.kernel.org X-Gm-Message-State: AOJu0YwPdi/Gf3+lcj/zpUtt2ATpi+G6LH5p42AZYJZmF3GCwpgK10Le I/6YWfl37O6GpuYSu5v8o8RWfguIApHoCl3MIwAHV1Qj63jQcNuHH5JVreODIeR/qgv8KqyenBx LKUXFtw== X-Received: from pfbfa30.prod.google.com ([2002:a05:6a00:2d1e:b0:829:9a65:4170]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1a8c:b0:800:8fdf:1a54 with SMTP id d2e1a72fcca58-829a2f4a0bbmr2373665b3a.34.1772812469067; Fri, 06 Mar 2026 07:54:29 -0800 (PST) Date: Fri, 6 Mar 2026 07:54:27 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251026201911.505204-1-xin@zytor.com> <20251026201911.505204-9-xin@zytor.com> Message-ID: Subject: Re: [PATCH v9 08/22] KVM: VMX: Set FRED MSR intercepts From: Sean Christopherson To: Chao Gao Cc: "Xin Li (Intel)" , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, peterz@infradead.org, andrew.cooper3@citrix.com, hch@infradead.org, sohil.mehta@intel.com Content-Type: text/plain; charset="us-ascii" On Fri, Mar 06, 2026, Chao Gao wrote: > On Wed, Mar 04, 2026 at 04:48:52PM -0800, Sean Christopherson wrote: > >On Wed, Nov 12, 2025, Chao Gao wrote: > >> On Sun, Oct 26, 2025 at 01:18:56PM -0700, Xin Li (Intel) wrote: > >> >From: Xin Li > >> > > >> >On a userspace MSR filter change, set FRED MSR intercepts. > >> > > >> >The eight FRED MSRs, MSR_IA32_FRED_RSP[123], MSR_IA32_FRED_STKLVLS, > >> >MSR_IA32_FRED_SSP[123] and MSR_IA32_FRED_CONFIG, are all safe to > >> >passthrough, because each has a corresponding host and guest field > >> >in VMCS. > >> > >> Sean prefers to pass through MSRs only when there is a reason to do that rather > >> than just because it is free. My thinking is that RSPs and SSPs are per-task > >> and are context-switched frequently, so we need to pass through them. But I am > >> not sure if there is a reason for STKLVLS and CONFIG. > > > >There are VMCS fields, at which point intercepting and emulating is probably > >more work than just letting the guest access directly. :-/ > > Just drop the MSR intercepting code and everything should work, right? KVM > needs to handle userspace writes anyway. so, there is no "more work" to me. True. I was thinking KVM would need to marshall the value to/from the hardware MSR, but that's obviously not necessary :-) (and also would be comically wrong). After working through the various implications, I think it makes to adjust the "rule" to be "if necessary for performance OR it's _completely_ free (minus the interception toggling)" (and in both cases, obviously disabling interception needs to be functionally safe/correct too). Because I think we'll end up with confusing code if we limit disable interception only for performance reasons. E.g. I can't imagine MSR_IA32_S_CET will get modified post-boot, so by the performance-only rule, KVM should always intercept S_CET. But MSR_IA32_U_CET can be read/written much more frequency, and so should be passed through. And then we'd end up intercept S_CET but not U_CET, which _looks_ wrong. The FRED MSRs fall into the same boat. Intercepting only STKLVLS and CONFIG is likely a-ok from a performance perspective, but once this is all merged and folks that weren't part of this discussion come along, readers will likely be wondering why STKLVLS and CONFIG are "missing". All in all, unless someone has an functional or performance argument against disabling interception, I think it makes sense to disabling interception for all FRED MSRs that are context switched by hardware.