From: Sean Christopherson <seanjc@google.com>
To: Chao Gao <chao.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [PATCH v2 3/3] KVM: x86: Add a module param to control and enumerate device posted IRQs
Date: Fri, 21 Mar 2025 13:44:47 -0700 [thread overview]
Message-ID: <Z93Pv0HWYvq9Nz2h@google.com> (raw)
In-Reply-To: <Z9zHju4PIJ+eunli@intel.com>
On Fri, Mar 21, 2025, Chao Gao wrote:
> On Thu, Mar 20, 2025 at 10:59:19AM -0700, Sean Christopherson wrote:
> >@@ -9776,8 +9777,8 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
> > if (r != 0)
> > goto out_mmu_exit;
> >
> >- enable_device_posted_irqs &= enable_apicv &&
> >- irq_remapping_cap(IRQ_POSTING_CAP);
> >+ enable_device_posted_irqs = allow_device_posted_irqs && enable_apicv &&
> >+ irq_remapping_cap(IRQ_POSTING_CAP);
>
> Can we simply drop this ...
>
> >
> > kvm_ops_update(ops);
> >
> >@@ -14033,6 +14034,8 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_rmp_fault);
> >
> > static int __init kvm_x86_init(void)
> > {
> >+ allow_device_posted_irqs = enable_device_posted_irqs;
> >+
> > kvm_init_xstate_sizes();
> >
> > kvm_mmu_x86_module_init();
> >
> >
> >Option #2 is to shove the module param into vendor code, but leave the variable
> >in kvm.ko, like we do for enable_apicv.
> >
> >I'm leaning toward option #2, as it's more flexible, arguably more intuitive, and
> >doesn't prevent putting the logic in kvm_x86_vendor_init().
> >
>
> and do
>
> bool kvm_arch_has_irq_bypass(void)
> {
> return enable_device_posted_irqs && enable_apicv &&
> irq_remapping_cap(IRQ_POSTING_CAP);
> }
That would avoid the vendor module issues, but it would result in
allow_device_posted_irqs not reflecting the state of KVM. We could partially
address that by having the variable incorporate irq_remapping_cap(IRQ_POSTING_CAP)
but not enable_apicv, but that's still a bit funky.
Given that enable_apicv already has the "variable in kvm.ko, module param in
kvm-{amd,intel}.ko" behavior, and that I am planning on giving enable_ipiv the
same treatment (long story), my strong vote is to go with option #2 as it's the
most flexibile, most accurate, and consistent with existing knobs.
next prev parent reply other threads:[~2025-03-21 20:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 14:20 [PATCH v2 0/3] KVM: x86: Add a module param for device posted IRQs Sean Christopherson
2025-03-20 14:20 ` [PATCH v2 1/3] KVM: VMX: Don't send UNBLOCK when starting device assignment without APICv Sean Christopherson
2025-03-20 14:20 ` [PATCH v2 2/3] KVM: SVM: Don't update IRTEs if APICv/AVIC is disable Sean Christopherson
2025-03-20 16:08 ` Jim Mattson
2025-03-20 14:20 ` [PATCH v2 3/3] KVM: x86: Add a module param to control and enumerate device posted IRQs Sean Christopherson
2025-03-20 16:02 ` Jim Mattson
2025-03-20 17:54 ` Sean Christopherson
2025-03-20 17:59 ` Sean Christopherson
2025-03-20 18:14 ` Yosry Ahmed
2025-03-21 1:57 ` Chao Gao
2025-03-21 20:44 ` Sean Christopherson [this message]
2025-03-24 9:26 ` Chao Gao
2025-03-24 13:41 ` 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=Z93Pv0HWYvq9Nz2h@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox