On 9 October 2020 00:27:06 BST, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: >On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote: >> On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote: >>> > >>> > (We'd want the x86_vector_domain to actually have an MSI compose >>> > function in the !CONFIG_PCI_MSI case if we did this, of course.) >>> >>> The compose function and the vector domain wrapper can simply move >to >>> vector.c >> >> I ended up putting __irq_msi_compose_msg() into apic.c and that way I >> can make virt_ext_dest_id static in that file. >> >> And then I can move all the HPET-MSI support into hpet.c too. > >Works for me. > >> >https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/ext_dest_id > >For the next submission, can you please > > - pick up the -ENODEV changes for HPET/IOAPIC which I posted earlier Ack. > - shuffle all that compose/IOAPIC cleanup around I'd prefer the MSI swizzling bit to stay last in the series. I want to stare hard at the hyperv-iommu part a bit more, and ideally even have it tested. I'd prefer the real functionality that I care about, not to depend on that cleanup. If it actually let me remove all mention of ext_dest_id from the IOAPIC code and use *only* MSI swizzling, I'd be keener to reorder. But as noted, there are a couple of manual RTE constructions in there still anyway. I can move __irq_compose_msi_msg() earlier in the series though, and then virt_ext_dest_id can be static in apic.c from its inception. OK? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
