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

From: Thomas Gleixner
Date: Mon Oct 12 2020 - 05:33:17 EST


On Sun, Oct 11 2020 at 22:15, David Woodhouse wrote:
> On 11 October 2020 18:12:08 BST, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> On Sat, Oct 10 2020 at 12:58, David Woodhouse wrote:
>>> On 10 October 2020 12:44:10 BST, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>> wrote:
>>> Yeah. There's some muttering to be done for HPET about whether it's
>>> *its* MSI domain or whether it's the parent domain. But I'll have a
>>> play. I think we'll be able to drop the whole
>>> irq_remapping_get_irq_domain() thing.
>>
>> That would be really nice.
>
> I can make it work for HPET if I fix up the point at which the IRQ
> remapping code registers a notifier on the platform bus. (At IRQ remap
> setup time is too early; when it registers the PCI bus notifier is too
> late.)
>
> IOAPIC is harder though as the platform bus doesn't even exist that
> early. Maybe an early platform bus is possible but it would have to
> turn out particularly simple to do, or I'd need to find another use
> case too, to justify it. Will continue to play....

You might want to look into using irq_find_matching_fwspec() instead for
both HPET and IOAPIC. That needs a select() callback implemented in the
remapping domains.

>> I go over it in the next days once more and stick it into my devel tree
>> until rc1. Need to get some conflicts sorted with that Device MSI
>> stuff.
>
> While playing with HPET I noticed I need
> s/CONFIG_PCI_MSI/CONFIG_IRQ_GENERIC_MSI/ where the variables are
> declared at the top of msi.c to match the change I made later on. Can
> post v3 of the series or you can silently fix it up as you go; please
> advise.

I think I might be able to handle that on my own :)

Thanks,

tglx