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

[Michael Kelley (LINUX)]

From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Tuesday, November 15, 2022 5:25 PM
> 
> On 11/14/2022 11:09 AM, Michael Kelley (LINUX) wrote:
> > From: Wei Liu <wei.liu@xxxxxxxxxx> 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@xxxxxxxxxx> 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.

Sounds good.  Please leave a comment somewhere in the code summarizing
what you found, and stating the expectation that ms_hyperv_msi_ext_dest_id()
returns "false" in the root partition.

Michael