From: David Woodhouse <dwmw2@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org
Cc: iommu <iommu@lists.linux-foundation.org>,
kvm <kvm@vger.kernel.org>,
linux-hyperv@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR
Date: Wed, 07 Oct 2020 18:34:49 +0100 [thread overview]
Message-ID: <dfa4bae7d298fa17dc427b5121b9ddc981fe0f49.camel@infradead.org> (raw)
In-Reply-To: <874kn63q7m.fsf@nanos.tec.linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]
On Wed, 2020-10-07 at 19:23 +0200, Thomas Gleixner wrote:
> > It so happens that in Linux, we don't really architect the software
> > like that. So each of the PCI MSI domain, HPET, and IOAPIC have their
> > *own* message composer which has the same limits and composes basically
> > the same messages as if it was *their* format, not dictated to them by
> > the APIC upstream. And that's what we're both getting our panties in a
> > knot about, I think.
>
> Are you actually reading what I write and caring to look at the code?
>
> PCI-MSI does not have a compose message callback in the irq chip. The
> message is composed by the underlying parent domain. Same for HPET.
>
> The only dogdy part is the IO/APIC for hysterical raisins and because
> I did not come around yet to sort that out.
Right. And the problem is that the "underlying parent domain" in this
case is actually x86_vector_domain. Whereas it probably makes more
sense, at least in theory, for there to be an *intermediate* domain
responsible for composing the Compat MSI messages.
Both the Compat-MSI and the IR-MSI domains would be children of the
generic x86_vector_domain, and then any given HPET, IOAPIC or PCI-MSI
domain would be a child of either one of those generic MSI domains.
> > It really doesn't matter that much to the underlying generic irqdomain
> > support for limited affinities. Except that you want to make the
> > generic code support the concept of a child domain supporting *more*
> > CPUs than its parent, which really doesn't make much sense if you think
> > about it.
>
> Right. So we really want to stick the restriction into a compat-MSI
> domain to make stuff match reality and to avoid banging the head against
> the wall sooner than later.
Right.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: David Woodhouse <dwmw2@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
iommu <iommu@lists.linux-foundation.org>,
linux-hyperv@vger.kernel.org, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR
Date: Wed, 07 Oct 2020 18:34:49 +0100 [thread overview]
Message-ID: <dfa4bae7d298fa17dc427b5121b9ddc981fe0f49.camel@infradead.org> (raw)
In-Reply-To: <874kn63q7m.fsf@nanos.tec.linutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 1790 bytes --]
On Wed, 2020-10-07 at 19:23 +0200, Thomas Gleixner wrote:
> > It so happens that in Linux, we don't really architect the software
> > like that. So each of the PCI MSI domain, HPET, and IOAPIC have their
> > *own* message composer which has the same limits and composes basically
> > the same messages as if it was *their* format, not dictated to them by
> > the APIC upstream. And that's what we're both getting our panties in a
> > knot about, I think.
>
> Are you actually reading what I write and caring to look at the code?
>
> PCI-MSI does not have a compose message callback in the irq chip. The
> message is composed by the underlying parent domain. Same for HPET.
>
> The only dogdy part is the IO/APIC for hysterical raisins and because
> I did not come around yet to sort that out.
Right. And the problem is that the "underlying parent domain" in this
case is actually x86_vector_domain. Whereas it probably makes more
sense, at least in theory, for there to be an *intermediate* domain
responsible for composing the Compat MSI messages.
Both the Compat-MSI and the IR-MSI domains would be children of the
generic x86_vector_domain, and then any given HPET, IOAPIC or PCI-MSI
domain would be a child of either one of those generic MSI domains.
> > It really doesn't matter that much to the underlying generic irqdomain
> > support for limited affinities. Except that you want to make the
> > generic code support the concept of a child domain supporting *more*
> > CPUs than its parent, which really doesn't make much sense if you think
> > about it.
>
> Right. So we really want to stick the restriction into a compat-MSI
> domain to make stuff match reality and to avoid banging the head against
> the wall sooner than later.
Right.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-10-07 17:34 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 15:28 [PATCH 0/13] Fix per-domain IRQ affinity, allow >255 CPUs on x86 without IRQ remapping David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 01/13] x86/apic: Use x2apic in guest kernels even with unusable CPUs David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 20:45 ` Thomas Gleixner
2020-10-06 20:45 ` Thomas Gleixner
2020-10-05 15:28 ` [PATCH 03/13] x86/ioapic: Handle Extended Destination ID field in RTE David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 04/13] x86/apic: Support 15 bits of APIC ID in IOAPIC/MSI where available David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 05/13] genirq: Prepare for default affinity to be passed to __irq_alloc_descs() David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:01 ` Thomas Gleixner
2020-10-06 21:01 ` Thomas Gleixner
2020-10-06 21:07 ` David Woodhouse
2020-10-06 21:07 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 06/13] genirq: Add default_affinity argument " David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:06 ` Thomas Gleixner
2020-10-06 21:06 ` Thomas Gleixner
2020-10-05 15:28 ` [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs() David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:26 ` Thomas Gleixner
2020-10-06 21:26 ` Thomas Gleixner
2020-10-07 7:19 ` David Woodhouse
2020-10-07 7:19 ` David Woodhouse
2020-10-07 13:37 ` Thomas Gleixner
2020-10-07 13:37 ` Thomas Gleixner
2020-10-07 14:10 ` David Woodhouse
2020-10-07 14:10 ` David Woodhouse
2020-10-07 15:57 ` Thomas Gleixner
2020-10-07 15:57 ` Thomas Gleixner
2020-10-07 16:11 ` David Woodhouse
2020-10-07 16:11 ` David Woodhouse
2020-10-07 20:53 ` Thomas Gleixner
2020-10-07 20:53 ` Thomas Gleixner
2020-10-08 7:21 ` David Woodhouse
2020-10-08 7:21 ` David Woodhouse
2020-10-08 9:34 ` Thomas Gleixner
2020-10-08 9:34 ` Thomas Gleixner
2020-10-08 11:10 ` David Woodhouse
2020-10-08 11:10 ` David Woodhouse
2020-10-08 12:40 ` Thomas Gleixner
2020-10-08 12:40 ` Thomas Gleixner
2020-10-09 7:54 ` David Woodhouse
2020-10-09 7:54 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 08/13] genirq: Add irq_domain_set_affinity() David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:32 ` Thomas Gleixner
2020-10-06 21:32 ` Thomas Gleixner
2020-10-07 7:22 ` David Woodhouse
2020-10-07 7:22 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 09/13] x86/irq: Add x86_non_ir_cpumask David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:42 ` Thomas Gleixner
2020-10-06 21:42 ` Thomas Gleixner
2020-10-07 7:25 ` David Woodhouse
2020-10-07 7:25 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-06 21:54 ` Thomas Gleixner
2020-10-06 21:54 ` Thomas Gleixner
2020-10-07 7:48 ` David Woodhouse
2020-10-07 7:48 ` David Woodhouse
2020-10-07 12:59 ` Thomas Gleixner
2020-10-07 12:59 ` Thomas Gleixner
2020-10-07 13:08 ` David Woodhouse
2020-10-07 13:08 ` David Woodhouse
2020-10-07 14:05 ` Thomas Gleixner
2020-10-07 14:05 ` Thomas Gleixner
2020-10-07 14:23 ` David Woodhouse
2020-10-07 14:23 ` David Woodhouse
2020-10-07 16:02 ` Thomas Gleixner
2020-10-07 16:02 ` Thomas Gleixner
2020-10-07 16:15 ` David Woodhouse
2020-10-07 16:15 ` David Woodhouse
2020-10-07 15:05 ` David Woodhouse
2020-10-07 15:05 ` David Woodhouse
2020-10-07 15:25 ` Thomas Gleixner
2020-10-07 15:25 ` Thomas Gleixner
2020-10-07 15:46 ` David Woodhouse
2020-10-07 15:46 ` David Woodhouse
2020-10-07 17:23 ` Thomas Gleixner
2020-10-07 17:23 ` Thomas Gleixner
2020-10-07 17:34 ` David Woodhouse [this message]
2020-10-07 17:34 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 11/13] x86/smp: Allow more than 255 CPUs even without interrupt remapping David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 12/13] iommu/irq_remapping: Kill most of hyperv-iommu.c now it's redundant David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID David Woodhouse
2020-10-05 15:28 ` David Woodhouse
2020-10-07 8:14 ` Paolo Bonzini
2020-10-07 8:14 ` Paolo Bonzini
2020-10-07 8:59 ` David Woodhouse
2020-10-07 8:59 ` David Woodhouse
2020-10-07 11:15 ` Paolo Bonzini
2020-10-07 11:15 ` Paolo Bonzini
2020-10-07 12:04 ` David Woodhouse
2020-10-07 12:04 ` David Woodhouse
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=dfa4bae7d298fa17dc427b5121b9ddc981fe0f49.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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 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.