All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry.ahmed@linux.dev>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jim Mattson <jmattson@google.com>,
	 Maxim Levitsky <mlevitsk@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH 4/6] KVM: SVM: Switch svm_copy_lbrs() to a macro
Date: Mon, 10 Nov 2025 11:41:05 -0800	[thread overview]
Message-ID: <aRI_0dBWvyu5HjTd@google.com> (raw)
In-Reply-To: <dyfu7nopxqtdw6k6s37dmq3wedqua2risfgolsltepykffqjkp@ij3ogvhxpvrg>

On Mon, Nov 10, 2025, Yosry Ahmed wrote:
> 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?

Base your patches on kvm/master, assuming there's nothing in kvm-x86/svm that
you need.  I can create a one-off branch, e.g. kvm-x86/lbrv, based on kvm/master
or 6.18-rc6.

  reply	other threads:[~2025-11-10 19:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-08  0:45 [PATCH 0/6] KVM: SVM: LBR virtualization fixes Yosry Ahmed
2025-11-08  0:45 ` [PATCH 1/6] KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is updated Yosry Ahmed
2025-11-09  7:42   ` Paolo Bonzini
2025-11-08  0:45 ` [PATCH 2/6] KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv() Yosry Ahmed
2025-11-11  3:11   ` Yosry Ahmed
2025-11-11 18:55     ` Yosry Ahmed
2025-11-11 22:30       ` Sean Christopherson
2025-11-08  0:45 ` [PATCH 3/6] KVM: nSVM: Fix and simplify LBR virtualization handling with nested Yosry Ahmed
2025-11-08  0:45 ` [PATCH 4/6] KVM: SVM: Switch svm_copy_lbrs() to a macro Yosry Ahmed
2025-11-09  7:59   ` Paolo Bonzini
2025-11-10 19:23     ` Yosry Ahmed
2025-11-10 19:41       ` Sean Christopherson [this message]
2025-11-08  0:45 ` [PATCH 5/6] KVM: SVM: Add missing save/restore handling of LBR MSRs Yosry Ahmed
2025-11-08  9:08   ` Yosry Ahmed
2025-11-08  0:45 ` [PATCH 6/6] KVM: selftests: Add a test for LBR save/restore (ft. nested) Yosry Ahmed
2025-11-09  7:57 ` [PATCH 0/6] KVM: SVM: LBR virtualization fixes Paolo Bonzini

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=aRI_0dBWvyu5HjTd@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=yosry.ahmed@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.