[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BYAPR21MB1688B634391F489450810499D7079@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Wed, 16 Nov 2022 18:49:41 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
Wei Liu <wei.liu@...nel.org>
CC: Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Dexuan Cui <decui@...rosoft.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"joro@...tes.org" <joro@...tes.org>,
"will@...nel.org" <will@...nel.org>
Subject: RE: [PATCH] iommu/hyper-v: Allow hyperv irq remapping without x2apic
From: Nuno Das Neves <nunodasneves@...ux.microsoft.com> Sent: Tuesday, November 15, 2022 5:25 PM
>
> On 11/14/2022 11:09 AM, Michael Kelley (LINUX) wrote:
> > From: Wei Liu <wei.liu@...nel.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@...nel.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.
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
Powered by blists - more mailing lists