Re: [PATCH 5/5] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

[David Woodhouse]

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.