On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote: > > > The information has to property of the relevant irq domains and the > > > hierarchy allows you nicely to retrieve it from there instead of > > > sprinkling this all over the place. > > > > No. This is not a property of the parent domain per se. Especially if > > you're thinking that we could inherit the affinity mask from the > > parent, then twice no. > > > > This is a property of the MSI domain itself, and how many bits of > > destination ID the hardware at *this* level can interpret and pass on > > to the parent domain. > > Errm what? > > The MSI domain does not know anything about what the underlying domain > can handle and it shouldn't. > > If MSI is on top of remapping then the remapping domain defines what the > MSI domain can do and not the other way round. Ditto for the non > remapped case in which the vector domain decides. > > The top most MSI irq chip does not even have a compose function, neither > for the remap nor for the vector case. The composition is done by the > parent domain from the data which the parent domain constructed. Same > for the IO/APIC just less clearly separated. > > The top most chip just takes what the underlying domain constructed and > writes it to the message store, because that's what the top most chip > controls. It does not control the content. Sure, whatever. The way we arrange the IRQ domain hierarchy in x86 Linux doesn't really match my understanding of the real hardware, or how qemu emulates it either. But it is at least internally self- consistent, and in this model it probably does make some sense to claim the 8-bit limit on x86_vector_domain itself, and *remove* that limit in the remapping irqdomain. Not really the important part to deal with right now, either way.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
