Re: [PATCH 4/6] KVM: SVM: Switch svm_copy_lbrs() to a macro

Yosry Ahmed
2025-11-10T19:23:58Z

On Sun, Nov 09, 2025 at 08:59:18AM +0100, Paolo Bonzini wrote:
> On 11/8/25 01:45, Yosry Ahmed wrote:
> > In preparation for using svm_copy_lbrs() with 'struct vmcb_save_area'
> > without a containing 'struct vmcb', and later even 'struct
> > vmcb_save_area_cached', make it a macro. Pull the call to
> > vmcb_mark_dirty() out to the callers.
>
> The changes to use `struct vmcb_save_area_cached' are not included in this
> series, so they are irrelevant.
>
> Since I've applied patches 1-3, which fix the worst bugs, there are two ways
> to handle the rest:
>
> * keep the function instead of the macro, while making it take a struct
> vmcb_save_area (and therefore pulling vmcb_mark_dirty() to the callers and
> fixing the bug you mention below).
>
> * you resubmit with the changes to use struct vmcb_save_area_cached, so that
> the commit message makes more sense.

I can include patches 4-6 with the respin of the series [1] that has the
changes to use `struct vmcb_save_area_cached`. That series origianlly
had the patch to switch svm_copy_lbrs() to a macro, but I moved it here
to use for the save/restore patch. I was planning to rebase [1] on top
of this series anyway.

There is a hiccup though, I assumed everything would go through Sean's
tree so I planned to respin [1] on top of this series. Otherwise, they
will conflict. With the first 3 patches in your tree, I am not sure how
that would work.

I can respin [1] on top of Sean's kvm-x86/next or kvm-x86/svm, but it
will conflict with the patches you picked up eventually, and I already
have them locally on top of the LBR fixes so it seems like wasted
effort.

Sean, Paolo, how do you want to handle this?

[1]https://lore.kernel.org/kvm/20251104195949.3528411-1-yosry.ahmed@linux.dev/

>
> Thanks,
>
> Paolo
>
> > Macros are generally not preferred compared to functions, mainly due to
> > type-safety. However, in this case it seems like having a simple macro
> > copying a few fields is better than copy-pasting the same 5 lines of
> > code in different places.
> >
> > On the bright side, pulling vmcb_mark_dirty() calls to the callers makes
> > it clear that in one case, vmcb_mark_dirty() was being called on VMCB12.
> > It is not architecturally defined for the CPU to clear arbitrary clean
> > bits, and it is not needed, so drop that one call.
>
> > Technically fixes the non-architectural behavior of setting the dirty
> > bit on VMCB12.
> >
> > Fixes: d20c796ca370 ("KVM: x86: nSVM: implement nested LBR virtualization")
> > Cc: stable@vger.kernel.org
> >
> > Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
> > ---
> > arch/x86/kvm/svm/nested.c | 16 ++++++++++------
> > arch/x86/kvm/svm/svm.c | 11 -----------
> > arch/x86/kvm/svm/svm.h | 10 +++++++++-
> > 3 files changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > index c81005b245222..e7861392f2fcd 100644
> > --- a/arch/x86/kvm/svm/nested.c
> > +++ b/arch/x86/kvm/svm/nested.c
> > @@ -676,10 +676,12 @@ static void nested_vmcb02_prepare_save(struct vcpu_svm *svm, struct vmcb *vmcb12
> > * Reserved bits of DEBUGCTL are ignored. Be consistent with
> > * svm_set_msr's definition of reserved bits.
> > */
> > - svm_copy_lbrs(vmcb02, vmcb12);
> > + svm_copy_lbrs(&vmcb02->save, &vmcb12->save);
> > + vmcb_mark_dirty(vmcb02, VMCB_LBR);
> > vmcb02->save.dbgctl &= ~DEBUGCTL_RESERVED_BITS;
> > } else {
> > - svm_copy_lbrs(vmcb02, vmcb01);
> > + svm_copy_lbrs(&vmcb02->save, &vmcb01->save);
> > + vmcb_mark_dirty(vmcb02, VMCB_LBR);
> > }
> > svm_update_lbrv(&svm->vcpu);
> > }
> > @@ -1186,10 +1188,12 @@ int nested_svm_vmexit(struct vcpu_svm *svm)
> > kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
> > if (unlikely(guest_cpu_cap_has(vcpu, X86_FEATURE_LBRV) &&
> > - (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK)))
> > - svm_copy_lbrs(vmcb12, vmcb02);
> > - else
> > - svm_copy_lbrs(vmcb01, vmcb02);
> > + (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK))) {
> > + svm_copy_lbrs(&vmcb12->save, &vmcb02->save);
> > + } else {
> > + svm_copy_lbrs(&vmcb01->save, &vmcb02->save);
> > + vmcb_mark_dirty(vmcb01, VMCB_LBR);
> > + }
> > svm_update_lbrv(vcpu);
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index fc42bcdbb5200..9eb112f0e61f0 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -795,17 +795,6 @@ static void svm_recalc_msr_intercepts(struct kvm_vcpu *vcpu)
> > */
> > }
> > -void svm_copy_lbrs(struct vmcb *to_vmcb, struct vmcb *from_vmcb)
> > -{
> > - to_vmcb->save.dbgctl = from_vmcb->save.dbgctl;
> > - to_vmcb->save.br_from = from_vmcb->save.br_from;
> > - to_vmcb->save.br_to = from_vmcb->save.br_to;
> > - to_vmcb->save.last_excp_from = from_vmcb->save.last_excp_from;
> > - to_vmcb->save.last_excp_to = from_vmcb->save.last_excp_to;
> > -
> > - vmcb_mark_dirty(to_vmcb, VMCB_LBR);
> > -}
> > -
> > static void __svm_enable_lbrv(struct kvm_vcpu *vcpu)
> > {
> > to_svm(vcpu)->vmcb->control.virt_ext |= LBR_CTL_ENABLE_MASK;
> > diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> > index c2acaa49ee1c5..e510c8183bd87 100644
> > --- a/arch/x86/kvm/svm/svm.h
> > +++ b/arch/x86/kvm/svm/svm.h
> > @@ -687,8 +687,16 @@ static inline void *svm_vcpu_alloc_msrpm(void)
> > return svm_alloc_permissions_map(MSRPM_SIZE, GFP_KERNEL_ACCOUNT);
> > }
> > +#define svm_copy_lbrs(to, from) \
> > +({ \
> > + (to)->dbgctl = (from)->dbgctl; \
> > + (to)->br_from = (from)->br_from; \
> > + (to)->br_to = (from)->br_to; \
> > + (to)->last_excp_from = (from)->last_excp_from; \
> > + (to)->last_excp_to = (from)->last_excp_to; \
> > +})
> > +
> > void svm_vcpu_free_msrpm(void *msrpm);
> > -void svm_copy_lbrs(struct vmcb *to_vmcb, struct vmcb *from_vmcb);
> > void svm_enable_lbrv(struct kvm_vcpu *vcpu);
> > void svm_update_lbrv(struct kvm_vcpu *vcpu);
> Since
>