All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Sairaj Kodilkar <sarunkod@amd.com>
Cc: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [RFC PATCH v3 5/6] KVM: SVM: Add support for AMD IOMMU Guest APIC Physical Processor Interrupt (GAPPI)
Date: Mon, 10 Aug 2026 17:43:55 -0700	[thread overview]
Message-ID: <anpwS3C2UIHFz_Uf@google.com> (raw)
In-Reply-To: <b50b3535-eaa1-4944-914d-0eea8dac0e06@amd.com>

On Mon, Aug 10, 2026, Sairaj Kodilkar wrote:
> On 7/13/2026 4:41 PM, sashiko-bot@kernel.org wrote:
> > [Severity: High]
> > Can an unprivileged user-space process trigger this WARN_ON?
> > 
> > When a vCPU is created, svm->gappi_cpu is initialized to -1 in
> > avic_init_vcpu(). It is only set to a valid CPU ID later during
> > __avic_vcpu_load().
> > 
> > If host user-space configures device interrupt routing via the KVM_IRQFD ioctl
> > before the vCPU runs, avic_pi_update_irte() is invoked. This will pass the
> > uninitialized svm->gappi_cpu (-1) down to this function, hitting the WARN_ON.
> > If the host has panic_on_warn enabled, this allows host userspace to trigger
> > a kernel panic.
> 
> This is a valid concern.
> 
> If host userspace attaches a bypass IRQ targeting a vCPU that has never
> been loaded. Functionally, there is nothing to do in that window. A vCPU
> that has never been loaded cannot be blocking, so no GAPPI wakeup is
> required. The IOMMU still posts the interrupt into the vAPIC backing
> page, and the pending IRR is evaluated at the first VMRUN after
> avic_vcpu_load(), which is also where the IRTE gets a valid Destination
> and IsRun = 1.
> 
> This can be resolved by assigning a arbitrary gappi destination, without
> actually updating the gappi wakeup list of that CPU.

With the disclaimer that I haven't look super closely at this series, and haven't
thought too deeply about the feature itself either...

Why are we doing anything different than what VMX does?  vCPUs on the wakeup
list when they block, and come off the list when they wakeup.  It's literally
one flow that's guarantee to pair put()+load(), and the logic for manipulating
the list is quite simple as a result.

Going a step further, why is GAPPI not sharing code with VMX Posted Interupts?
At a glance, the only meaningful difference in the wakeup flow is the "should
this particular vCPU be awakened".

  reply	other threads:[~2026-08-11  0:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13 10:50 [RFC PATCH v3 0/6] Add support for AMD IOMMU GAPPI Sairaj Kodilkar
2026-07-13 10:50 ` [RFC PATCH v3 1/6] iommu/amd: KVM: SVM: Rename cpu to apicid in IOMMU interface Sairaj Kodilkar
2026-07-13 10:50 ` [RFC PATCH v3 2/6] iommu/amd: KVM: SVM: Rename ga_log_intr to wakeup_intr " Sairaj Kodilkar
2026-07-13 10:50 ` [RFC PATCH v3 3/6] iommu/amd: KVM: SVM: Add explicit vCPU running state to " Sairaj Kodilkar
2026-07-13 11:08   ` sashiko-bot
2026-08-10  5:06     ` Sairaj Kodilkar
2026-08-11  0:34   ` Sean Christopherson
2026-07-13 10:50 ` [RFC PATCH v3 4/6] iommu/amd: Program guest-mode IRTEs for GAPPI wakeup when IRTE[IsRun] = 0 Sairaj Kodilkar
2026-07-13 11:07   ` sashiko-bot
2026-08-10  5:14     ` Sairaj Kodilkar
2026-07-13 10:50 ` [RFC PATCH v3 5/6] KVM: SVM: Add support for AMD IOMMU Guest APIC Physical Processor Interrupt (GAPPI) Sairaj Kodilkar
2026-07-13 11:11   ` sashiko-bot
2026-07-13 12:56     ` Sairaj Kodilkar
2026-08-11  0:40       ` Sean Christopherson
2026-08-10  5:54     ` Sairaj Kodilkar
2026-08-11  0:43       ` Sean Christopherson [this message]
2026-07-13 10:50 ` [RFC PATCH v3 6/6] iommu/amd: Provide kernel command line option to enable GAPPI Sairaj Kodilkar
2026-07-13 11:11   ` sashiko-bot
2026-08-10  6:12     ` Sairaj Kodilkar
2026-08-10  9:21 ` [RFC PATCH v3 0/6] Add support for AMD IOMMU GAPPI Sairaj Kodilkar
2026-08-11  0:48 ` Sean Christopherson

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=anpwS3C2UIHFz_Uf@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=sarunkod@amd.com \
    --cc=sashiko-reviews@lists.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.