From: Sean Christopherson <seanjc@google.com>
To: Michael Roth <michael.roth@amd.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
"Ackerley Tng" <ackerleytng@google.com>,
"Hyunwoo Kim" <imv4bel@gmail.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Jörg Rödel" <joro@8bytes.org>, "Fuad Tabba" <tabba@google.com>
Subject: Re: [PATCH v3 11/12] KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=y
Date: Mon, 6 Jul 2026 16:16:40 -0700 [thread overview]
Message-ID: <akw3WA9IduOkTK0C@google.com> (raw)
In-Reply-To: <mxhv67srfonr2nh7eoecujibf2umlbhyrhutdiizmm7qimrwyq@c357mnkz7lvi>
On Wed, Jul 01, 2026, Michael Roth wrote:
> On Tue, Jun 30, 2026 at 03:26:06PM -0700, Sean Christopherson wrote:
> > Wrap the .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE so that
> > non-SEV code doesn't try to wire up a callback without doing the necessary
> > enabling.
> >
> > No functional change intended.
> >
> > Fixes: 3bb2531e20bf ("KVM: guest_memfd: Add hook for initializing memory")
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
>
> Reviewed-by: Michael Roth <michael.roth@amd.com>
>
> Not sure about the need for the Fixes tag, but it certainly guards against
> some future problems.
Copy+pasting my response[*] from a similar comment about a liberal Fixes tag:
: > This LGTM, though I'm not sure this deserves a fixes tag.
:
: Yeah, it's borderline. Because KVM (x86) doesn't do AUTOSEL, i.e. requires an
: explicit "Cc: stable@vger.kernel.org" for the vast majority of cases, we can be
: very liberal with Fixes. And so I like to use Fixes to create a paper trail for
: anything where a commit did something that would have necessitate a new version
: of the patch, had it been caught in code review.
[*] https://lore.kernel.org/all/akMLDayXmzhmvJBG@google.com
next prev parent reply other threads:[~2026-07-06 23:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 22:25 [PATCH v3 00/12] KVM: SEV: Fix RMP #PF due to freeing in-use VMSA Sean Christopherson
2026-06-30 22:25 ` [PATCH v3 01/12] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests Sean Christopherson
2026-07-01 19:33 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 02/12] KVM: SEV: Extract loading of guest-provided VMSA to a separate helper Sean Christopherson
2026-07-01 19:34 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 03/12] KVM: SEV: Mark vCPU RUNNABLE after AP_CREATE, even if VMSA is unusable Sean Christopherson
2026-07-01 19:36 ` Michael Roth
2026-06-30 22:25 ` [PATCH v3 04/12] KVM: Rename .gmem_invalidate() to .gmem_reclaim_memory() Sean Christopherson
2026-06-30 22:39 ` sashiko-bot
2026-07-01 19:41 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 05/12] KVM: x86: Serialize writes to disabled_quirks using kvm->lock Sean Christopherson
2026-07-01 21:59 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 06/12] KVM: x86: Ensure runtime reads of disabled_quirks are resolved once Sean Christopherson
2026-07-01 22:00 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 07/12] KVM: x86/mmu: Fold kvm_mmu_zap_memslot() into kvm_arch_flush_shadow_memslot() Sean Christopherson
2026-07-01 22:04 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 08/12] KVM: x86/mmu: Split kvm_mmu_zap_all_fast() into "front" and "back" halves Sean Christopherson
2026-07-01 22:07 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 09/12] KVM: x86/mmu: Use split "zap all fast" helpers when invalidating memslot Sean Christopherson
2026-07-01 22:19 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 10/12] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Sean Christopherson
2026-07-01 21:56 ` Michael Roth
2026-06-30 22:26 ` [PATCH v3 11/12] KVM: x86: Guard .gmem_prepare() declarations with HAVE_KVM_GMEM_PREPARE=y Sean Christopherson
2026-07-01 22:42 ` Michael Roth
2026-07-06 23:16 ` Sean Christopherson [this message]
2026-06-30 22:26 ` [PATCH v3 12/12] KVM: SEV: Mark vCPU has having guest-provided VMSA even if its invalid Sean Christopherson
2026-07-01 22:47 ` Michael Roth
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=akw3WA9IduOkTK0C@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=imv4bel@gmail.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=tabba@google.com \
--cc=thomas.lendacky@amd.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 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.