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:
smime.p7s
Description: S/MIME cryptographic signature
