Re: [PATCH] iommu/hyper-v: Allow hyperv irq remapping without x2apic

[Nuno Das Neves <nunodasneves@linux.microsoft.com>]

On 11/14/2022 11:09 AM, Michael Kelley (LINUX) wrote:
> From: Wei Liu <wei.liu@kernel.org> Sent: Monday, November 14, 2022 5:59 AM
>>
>> On Fri, Nov 11, 2022 at 02:53:59PM -0800, Nuno Das Neves wrote:
>>> On 11/11/2022 9:58 AM, Michael Kelley (LINUX) wrote:
>>>> From: Wei Liu <wei.liu@kernel.org> Sent: Friday, November 11, 2022 9:27 AM
>> [...]
>>>
>>> I've tested this patch on these Azure SKUs:
>>> - Standard_D2S_v2 (intel xapic)
>>> - Standard_D4ds_v4 (intel xapic)
>>> - Standard_D4ds_v5 (intel x2apic)
>>> - Standard_D4ads_v5 (amd xapic)
>>>
>>> I've tested with linux Dom0 (nested hyperv root partition) and as a
>>> regular L1 guest.
>>>
>>
>> Okay. I think your tests are good.
>>
>> Michael, do you have any further concern?
>>
> 
> If ms_hyperv_msi_ext_dest_id() returns "true", then
> hyperv_prepare_irq_remapping() will still return -ENODEV and you
> won't get interrupt remapping because it isn't needed, at least not
> for guest VMs.  Is that what we want for the root partition?  Or does
> ms_hyperv_msi_ext_dest_id() only return true in a guest partition,
> and not in the root partition?  See commit d981059e13ff.
> 

I did some digging, and I *think* this function will always return "false"
in the root partition.

The cpuids (HYPERV_CPUID_VIRT_STACK_*) that determine the result of
ms_hyperv_msi_ext_dest_id() are implemented by the virtualization stack
in Azure, so for L1 guests it depends on that.

But, for nested root, the nested hypervisor controls which cpuids the
root partition sees, and VIRTUALIZATION_STACK_CPUID_INTERFACE is not in
that list.

I tested this too; if I boot the kernel with an L1 guest, I can see that
the HYPERV_CPUID_VIRT_STACK_INTERFACE contains the "VS#1" signature.
If I boot as L2 Root, the signature is not present.

I'm reasonably certain, but if I'm wrong we'll see the same breakage for
the same reason and we can fix it I guess.