From: Binbin Wu <binbin.wu@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Chao Gao <chao.gao@intel.com>, Borislav Petkov <bp@alien8.de>,
Xin Li <xin@zytor.com>, Dapeng Mi <dapeng1.mi@linux.intel.com>,
Francesco Lavra <francescolavra.fl@gmail.com>,
Manali Shukla <Manali.Shukla@amd.com>
Subject: Re: [PATCH v2 09/32] KVM: SVM: Clean up macros related to architectural MSRPM definitions
Date: Wed, 11 Jun 2025 14:09:18 +0800 [thread overview]
Message-ID: <5a80916b-1572-479b-a502-8b2d79c1dec3@linux.intel.com> (raw)
In-Reply-To: <20250610225737.156318-10-seanjc@google.com>
On 6/11/2025 6:57 AM, Sean Christopherson wrote:
> Move SVM's MSR Permissions Map macros to svm.h in antipication of adding
antipication -> anticipation?
> helpers that are available to SVM code, and opportunistically replace a
> variety of open-coded literals with (hopefully) informative macros.
>
> Opportunistically open code ARRAY_SIZE(msrpm_ranges) instead of wrapping
> it as NUM_MSR_MAPS, which is an ambiguous name even if it were qualified
> with "SVM_MSRPM".
>
> Deliberately leave the ranges as open coded literals, as using macros to
> define the ranges actually introduces more potential failure points, since
> both the definitions and the usage have to be careful to use the correct
> index. The lack of clear intent behind the ranges will be addressed in
> future patches.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
[...]
next prev parent reply other threads:[~2025-06-11 6:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 22:57 [PATCH v2 00/32] KVM: x86: Clean up MSR interception code Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 01/32] KVM: SVM: Disable interception of SPEC_CTRL iff the MSR exists for the guest Sean Christopherson
2025-06-11 4:38 ` Binbin Wu
2025-06-11 7:14 ` Binbin Wu
2025-06-10 22:57 ` [PATCH v2 02/32] KVM: SVM: Allocate IOPM pages after initial setup in svm_hardware_setup() Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 03/32] KVM: SVM: Don't BUG if setting up the MSR intercept bitmaps fails Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 04/32] KVM: SVM: Tag MSR bitmap initialization helpers with __init Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 05/32] KVM: SVM: Use ARRAY_SIZE() to iterate over direct_access_msrs Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 06/32] KVM: SVM: Kill the VM instead of the host if MSR interception is buggy Sean Christopherson
2025-06-11 2:16 ` Mi, Dapeng
2025-06-10 22:57 ` [PATCH v2 07/32] KVM: x86: Use non-atomic bit ops to manipulate "shadow" MSR intercepts Sean Christopherson
2025-06-11 6:38 ` Binbin Wu
2025-06-10 22:57 ` [PATCH v2 08/32] KVM: SVM: Massage name and param of helper that merges vmcb01 and vmcb12 MSRPMs Sean Christopherson
2025-06-11 2:22 ` Mi, Dapeng
2025-06-10 22:57 ` [PATCH v2 09/32] KVM: SVM: Clean up macros related to architectural MSRPM definitions Sean Christopherson
2025-06-11 6:09 ` Binbin Wu [this message]
2025-06-10 22:57 ` [PATCH v2 10/32] KVM: nSVM: Use dedicated array of MSRPM offsets to merge L0 and L1 bitmaps Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 11/32] KVM: nSVM: Omit SEV-ES specific passthrough MSRs from L0+L1 bitmap merge Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 12/32] KVM: nSVM: Don't initialize vmcb02 MSRPM with vmcb01's "always passthrough" Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 13/32] KVM: SVM: Add helpers for accessing MSR bitmap that don't rely on offsets Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 14/32] KVM: SVM: Implement and adopt VMX style MSR intercepts APIs Sean Christopherson
2025-06-11 7:31 ` Binbin Wu
2025-06-10 22:57 ` [PATCH v2 15/32] KVM: SVM: Pass through GHCB MSR if and only if VM is an SEV-ES guest Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 16/32] KVM: SVM: Drop "always" flag from list of possible passthrough MSRs Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 17/32] KVM: x86: Move definition of X2APIC_MSR() to lapic.h Sean Christopherson
2025-06-11 2:29 ` Mi, Dapeng
2025-06-10 22:57 ` [PATCH v2 18/32] KVM: VMX: Manually recalc all MSR intercepts on userspace MSR filter change Sean Christopherson
2025-06-11 6:52 ` Binbin Wu
2025-06-10 22:57 ` [PATCH v2 19/32] KVM: SVM: " Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 20/32] KVM: x86: Rename msr_filter_changed() => recalc_msr_intercepts() Sean Christopherson
2025-06-11 7:09 ` Binbin Wu
2025-06-10 22:57 ` [PATCH v2 21/32] KVM: SVM: Rename init_vmcb_after_set_cpuid() to make it intercepts specific Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 22/32] KVM: SVM: Fold svm_vcpu_init_msrpm() into its sole caller Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 23/32] KVM: SVM: Merge "after set CPUID" intercept recalc helpers Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 24/32] KVM: SVM: Drop explicit check on MSRPM offset when emulating SEV-ES accesses Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 25/32] KVM: SVM: Move svm_msrpm_offset() to nested.c Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 26/32] KVM: SVM: Store MSRPM pointer as "void *" instead of "u32 *" Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 27/32] KVM: nSVM: Access MSRPM in 4-byte chunks only for merging L0 and L1 bitmaps Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 28/32] KVM: SVM: Return -EINVAL instead of MSR_INVALID to signal out-of-range MSR Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 29/32] KVM: nSVM: Merge MSRPM in 64-bit chunks on 64-bit kernels Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 30/32] KVM: SVM: Add a helper to allocate and initialize permissions bitmaps Sean Christopherson
2025-06-10 22:57 ` [PATCH v2 31/32] KVM: x86: Simplify userspace filter logic when disabling MSR interception Sean Christopherson
2025-06-11 2:35 ` Mi, Dapeng
2025-06-10 22:57 ` [PATCH v2 32/32] KVM: selftests: Verify KVM disable interception (for userspace) on filter change Sean Christopherson
2025-06-24 19:38 ` [PATCH v2 00/32] KVM: x86: Clean up MSR interception code Sean Christopherson
2025-06-25 12:03 ` Manali Shukla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a80916b-1572-479b-a502-8b2d79c1dec3@linux.intel.com \
--to=binbin.wu@linux.intel.com \
--cc=Manali.Shukla@amd.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=francescolavra.fl@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox