From: Peter Xu <peterx@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Jan Kiszka <jan.kiszka@web.de>,
qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net,
ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com,
mst@redhat.com, pbonzini@redhat.com, alex.williamson@redhat.com,
wexu@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU
Date: Tue, 3 May 2016 11:22:16 +0800 [thread overview]
Message-ID: <20160503032216.GA3296@pxdev.xzpeter.org> (raw)
In-Reply-To: <20160429195214.GG15747@potion>
On Fri, Apr 29, 2016 at 09:52:14PM +0200, Radim Krčmář wrote:
> 2016-04-28 17:18+0800, Peter Xu:
> > On Thu, Apr 28, 2016 at 09:19:28AM +0200, Jan Kiszka wrote:
> >> Instead of fiddling with irq routes for the IOAPIC - where we don't need
> >> it -, I would suggest to do the following: Send IOAPIC events via
> >> kvm_irqchip_send_msi to the kernel. Only irqfd users (vhost, vfio)
> >> should use the pattern you are now applying to the IOAPIC: establish
> >> static routes as an irqfd is set up, and that route should be translated
> >> by the iommu first, register an IEC notifier to update any affected
> >> route when the iommu translation changes.
> >
> > Yes, maybe that's the right thing to do. Or say, when split irqchip,
> > IOAPIC can avoid using GSI routes any more. If with that, I should
> > also remove lots of things, like: IEC notifiers for IOAPIC, and all
> > things related to msi route sync-up in IOAPIC codes with KVM (so I
> > suppose we will save 24 gsi route entries for KVM, which sounds
> > good).
>
> Sadly, we can't get rid of those GSI routes. KVM uses them to decide
> whether it should forward EOI to userspace. And QEMU also has to remap
> them, because KVM uses dest_id for that decision.
Thanks to point out. Actually I have started to test the new patch
and did encountered issue when using split irqchip mode. The above
explains. :)
So I think I will keep this part of codes un-touched in this
series, and I can move forward with IR changes.
However, I am still wondering whether we can avoid this in KVM when
when using split irqchip mode? E.g., what if we do not do this check
in KVM and let all EOI be passed to userspace? Like:
---
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 36591fa..c0a6e51 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -936,10 +936,6 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
{
int trigger_mode;
- /* Eoi the ioapic only if the ioapic doesn't own the vector. */
- if (!kvm_ioapic_handles_vector(apic, vector))
- return;
-
/* Request a KVM exit to inform the userspace IOAPIC. */
if (irqchip_split(apic->vcpu->kvm)) {
apic->vcpu->arch.pending_ioapic_eoi = vector;
@@ -947,6 +943,10 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
return;
}
+ /* Eoi the ioapic only if the ioapic doesn't own the vector. */
+ if (!kvm_ioapic_handles_vector(apic, vector))
+ return;
+
if (apic_test_vector(vector, apic->regs + APIC_TMR))
trigger_mode = IOAPIC_LEVEL_TRIG;
else
---
I believe this will brings more user-space context switches, I just
do not know how this will impact the system (only for curiosity :).
Thanks,
-- peterx
next prev parent reply other threads:[~2016-05-03 3:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 7:05 [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 01/18] acpi: enable INTR for DMAR report structure Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 02/18] intel_iommu: allow queued invalidation for IR Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 03/18] intel_iommu: set IR bit for ECAP register Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 04/18] acpi: add DMAR scope definition for root IOAPIC Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 05/18] intel_iommu: define interrupt remap table addr register Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 06/18] intel_iommu: handle interrupt remap enable Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 07/18] intel_iommu: define several structs for IOMMU IR Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 08/18] intel_iommu: provide helper function vtd_get_iommu Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 09/18] intel_iommu: add IR translation faults defines Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 10/18] intel_iommu: Add support for PCI MSI remap Peter Xu
2016-04-28 7:32 ` Jan Kiszka
2016-04-28 8:06 ` Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 11/18] q35: ioapic: add support for emulated IOAPIC IR Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 12/18] ioapic: introduce ioapic_entry_parse() helper Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 13/18] intel_iommu: add support for split irqchip Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 14/18] q35: add "intremap" parameter to enable IR Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers Peter Xu
2016-04-28 7:26 ` Jan Kiszka
2016-04-28 8:29 ` Peter Xu
2016-04-28 8:36 ` Jan Kiszka
2016-04-28 8:49 ` Peter Xu
2016-04-28 15:56 ` David Kiarie
2016-04-29 2:43 ` Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 16/18] ioapic: register VT-d IEC invalidate notifier Peter Xu
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 17/18] ioapic: keep RO bits for IOAPIC entry Peter Xu
2016-04-29 19:42 ` Radim Krčmář
2016-04-28 7:05 ` [Qemu-devel] [PATCH v5 18/18] ioapic: clear remote irr bit for edge-triggered interrupts Peter Xu
2016-04-29 19:46 ` Radim Krčmář
2016-04-28 7:12 ` [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU Peter Xu
2016-04-28 7:19 ` Jan Kiszka
2016-04-28 9:18 ` Peter Xu
2016-04-28 9:32 ` Jan Kiszka
2016-04-29 19:52 ` Radim Krčmář
2016-05-03 3:22 ` Peter Xu [this message]
2016-05-03 4:38 ` Jan Kiszka
2016-05-03 5:30 ` Peter Xu
2016-05-03 5:40 ` Jan Kiszka
2016-05-03 6:00 ` Peter Xu
2016-05-03 6:09 ` Jan Kiszka
2016-05-09 11:50 ` Paolo Bonzini
2016-04-28 9:30 ` [Qemu-devel] [PATCH 19/18] intel_iommu: Add support for Extended Interrupt Mode Jan Kiszka
2016-04-29 2:54 ` Peter Xu
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=20160503032216.GA3296@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=jan.kiszka@web.de \
--cc=jasowang@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=rth@twiddle.net \
--cc=wexu@redhat.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.