On Thu, 2020-10-08 at 11:34 +0200, Thomas Gleixner wrote:
> The overall conclusion for this is:
> 
>  1) X2APIC support on bare metal w/o irq remapping is not going to
>     happen unless you:
> 
>       - added support in multi-queue devices which utilize managed
>         interrupts
>         
>       - audited the whole tree for other assumptions related to the
>         reachability of possible CPUs.
> 
>     I'm not expecting you to be done with that before I retire so for
>     me it's just not going to happen :)

Makes sense. It probably does mean we should a BUG_ON for the case
where IRQ remapping *is* enabled but any device is found which isn't
behind it. But that's OK.

>  2) X2APIC support on VIRT is possible if the extended ID magic is
>     supported by the hypervisor because that does not make any CPU
>     unreachable for MSI and therefore the multi-queue muck and
>     everything else just works.
> 
>     This requires to have either the domain affinity limitation for HPET
>     in place or just to force disable HPET or at least HPET-MSI which is
>     a reasonable tradeoff.
> 
>     HPET is not required for guests which have kvmclock and
>     APIC/deadline timer and known (hypervisor provided) frequencies.

HPET-MSI should work fine. Like the IOAPIC, it's just a child of the
*actual* MSI domain. The address/data in the MSI message are completely
opaque to it, and if the parent domain happens to put meaningful
information into bits 11-5 of the MSI address, the HPET won't even
notice.

The HPET's Tn_FSB_INT_ADDR register does have a full 32 bits of the MSI
address; it's not doing bit-swizzling like the IOAPIC does, which might
potentially *not* have been able to set certain bits in the MSI.