From: "Yosry Ahmed" <yosry.ahmed@linux.dev>
To: "Sean Christopherson" <seanjc@google.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v4 01/26] KVM: SVM: Switch svm_copy_lbrs() to a macro
Date: Fri, 06 Feb 2026 01:12:38 +0000 [thread overview]
Message-ID: <b92c2a7c7bcdc02d49eb0c0d481f682bf5d10c76@linux.dev> (raw)
In-Reply-To: <aYU87QeMg8_kTM-G@google.com>
February 5, 2026 at 4:59 PM, "Sean Christopherson" <seanjc@google.com> wrote:
>
> On Thu, Jan 15, 2026, 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.
> >
> > 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.
> >
> Stop. Bundling. Things. Together.
>
> /shakes fist angrily
>
> I was absolutely not expecting a patch titled "KVM: SVM: Switch svm_copy_lbrs()
> to a macro" to end with a Fixes tag, and I was *really* not expecting it to also
> be Cc'd for stable.
>
> At a glance, I genuinely can't tell if you added a Fixes to scope the backport,
> or because of the dirty vmcb12 bits thing.
>
> First fix the dirty behavior (and probably tag it for stable to avoid creating
> an unnecessary backport conflict), then in a separate patch macrofy the helper.
> Yeah, checkpatch will "suggest" that the stable@ patch should have Fixes, but
> for us humans, that's _useful_ information, because it says "hey you, this is a
> dependency for an upcoming fix!". As written, I look at this patch and go "huh?".
> (and then I look at the next patch and it all makes sense).
I agree, but fixing the dirty behavior on its own requires open-coding the function, then the following patch would change it to a macro and use it again. I was trying to minimize the noise of moving code back and forth..
next prev parent reply other threads:[~2026-02-06 1:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260115011312.3675857-1-yosry.ahmed@linux.dev>
2026-01-15 1:12 ` [PATCH v4 01/26] KVM: SVM: Switch svm_copy_lbrs() to a macro Yosry Ahmed
2026-02-06 0:59 ` Sean Christopherson
2026-02-06 1:12 ` Yosry Ahmed [this message]
2026-02-06 1:25 ` Sean Christopherson
2026-02-06 15:13 ` Yosry Ahmed
2026-02-06 15:54 ` Sean Christopherson
2026-01-15 1:12 ` [PATCH v4 02/26] KVM: SVM: Add missing save/restore handling of LBR MSRs Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 04/26] KVM: nSVM: Always inject a #GP if mapping VMCB12 fails on nested VMRUN Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 05/26] KVM: nSVM: Triple fault if mapping VMCB12 fails on nested #VMEXIT Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 06/26] KVM: nSVM: Triple fault if restore host CR3 " Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 07/26] KVM: nSVM: Drop nested_vmcb_check_{save/control}() wrappers Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 08/26] KVM: nSVM: Call enter_guest_mode() before switching to VMCB02 Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 09/26] KVM: nSVM: Make nested_svm_merge_msrpm() return an errno Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 10/26] KVM: nSVM: Call nested_svm_merge_msrpm() from enter_svm_guest_mode() Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 11/26] KVM: nSVM: Call nested_svm_init_mmu_context() before switching to VMCB02 Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 12/26] KVM: nSVM: Refactor minimal #VMEXIT handling out of nested_svm_vmexit() Yosry Ahmed
2026-01-15 1:12 ` [PATCH v4 13/26] KVM: nSVM: Unify handling of VMRUN failures with proper cleanup Yosry Ahmed
2026-02-06 0:47 ` Sean Christopherson
2026-02-06 15:40 ` Yosry Ahmed
2026-02-06 1:20 ` Sean Christopherson
2026-01-15 1:13 ` [PATCH v4 14/26] KVM: nSVM: Clear EVENTINJ field in VMCB12 on nested #VMEXIT Yosry Ahmed
2026-01-15 1:13 ` [PATCH v4 15/26] KVM: nSVM: Drop the non-architectural consistency check for NP_ENABLE Yosry Ahmed
2026-01-15 1:13 ` [PATCH v4 16/26] KVM: nSVM: Add missing consistency check for nCR3 validity Yosry Ahmed
2026-01-22 1:38 ` Yosry Ahmed
2026-01-15 1:13 ` [PATCH v4 17/26] KVM: nSVM: Add missing consistency check for hCR0.PG and NP_ENABLE Yosry Ahmed
2026-01-15 1:13 ` [PATCH v4 18/26] KVM: nSVM: Add missing consistency check for EFER, CR0, CR4, and CS Yosry Ahmed
2026-01-15 1:13 ` [PATCH v4 19/26] KVM: nSVM: Add missing consistency check for event_inj Yosry Ahmed
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=b92c2a7c7bcdc02d49eb0c0d481f682bf5d10c76@linux.dev \
--to=yosry.ahmed@linux.dev \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=stable@vger.kernel.org \
/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