From: Michael Kelley <mikelley@microsoft.com> To: Marc Zyngier <marc.zyngier@arm.com>, KY Srinivasan <kys@microsoft.com>, "will.deacon@arm.com" <will.deacon@arm.com>, "catalin.marinas@armm.com" <catalin.marinas@armm.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>, "olaf@aepfle.de" <olaf@aepfle.de>, "apw@canonical.com" <apw@canonical.com>, "jasowang@redhat.com" <jasowang@redhat.com>, Stephen Hemminger <sthemmin@microsoft.com>, vkuznets <vkuznets@redhat.com> Subject: RE: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor Date: Fri, 4 Jan 2019 20:05:10 +0000 [thread overview] Message-ID: <CY4PR21MB077301ECE13325F8C75EE941D78E0@CY4PR21MB0773.namprd21.prod.outlook.com> (raw) In-Reply-To: <e0374a07-809c-cabd-2eb6-e6b5ad84742e@arm.com> From: Marc Zyngier <marc.zyngier@arm.com> Sent: Thursday, December 13, 2018 3:23 AM > >> As Will said, this isn't a viable option. Please follow SMCCC 1.1. > > > > I'll have to start a conversation with the Hyper-V team about this. > > I don't know why they chose to use HVC #1 or this register scheme > > for output values. It may be tough to change at this point because > > there are Windows guests on Hyper-V for ARM64 that are already > > using this approach. > > I appreciate you already have stuff in the wild, but there is definitely > a case to be made for supporting architecturally specified mechanisms in > a hypervisor, and SMCCC is definitely part of it (I'm certainly curious > of how you support the Spectre mitigation otherwise). > The Hyper-V guys I need to discuss this with are not back from the holidays until January 7th. I'll follow up on this thread once I've had that conversation. > >>> +static int hv_cpu_init(unsigned int cpu) > >>> +{ > >>> + u64 msr_vp_index; > >>> + > >>> + hv_get_vp_index(msr_vp_index); > >>> + > >>> + hv_vp_index[smp_processor_id()] = msr_vp_index; > >>> + > >>> + if (msr_vp_index > hv_max_vp_index) > >>> + hv_max_vp_index = msr_vp_index; > >>> + > >>> + return 0; > >>> +} > >> > >> Is that some new way to describe a CPU topology? If so, why isn't that > >> exposed via the ACPI tables that the kernel already parses? > > > > Hyper-V's hypercall interface uses vCPU identifiers that are not > > guaranteed to be consecutive integers or to match what ACPI shows. > > No topology information is implied -- it's just unique identifiers. The > > hv_vp_index array provides easy mapping from Linux's consecutive > > integer IDs for CPUs when needed to construct hypercall arguments. > > That's extremely odd. The hypervisor obviously knows which vCPU is doing > a hypercall, and if referencing another vCPU, the virtualized MPIDR_EL1 > value should be used. I don't think deviating from the architecture is a > good idea (but I appreciate this is none of your doing). Following the > architecture would allow this code to directly use the cpu_logical_map > infrastructure we already have. I see what you are getting at. However, some Hyper-V hypercalls allow specifying arbitrary sets of vCPUs. These hypercalls are used to define target processors in the virtual PCI code (which I have not yet brought over to ARM64) and in enlightenments for IPIs and TLB flushes (used by Windows guests and Linux guests on x86, but not yet brought over to Linux ARM64, if they ever will be). These hypercalls take bitmaps as arguments, similar to a Linux cpumask, as defined in Sections 7.8.7.3 thru 7.8.7.5 in the Hyper-V TLFS. So Hyper-V defines its own VP index that is akin to the index into the cpu_logical_map, though it may not be the same mapping. My earlier comments may have been misleading -- the Hyper-V VP index is an integer ranging from 0 thru (# vCPUs - 1). With these requirements, Hyper-V defining its own VP index seems like a reasonable thing to do. And since Hyper-V provides the same hypercall interfaces for both x86 and ARM64 implementations, and for Windows guests, there's not much choice but to use the Hyper-V VP index as specified. Michael
WARNING: multiple messages have this Message-ID (diff)
From: Michael Kelley <mikelley@microsoft.com> To: Marc Zyngier <marc.zyngier@arm.com>, KY Srinivasan <kys@microsoft.com>, "will.deacon@arm.com" <will.deacon@arm.com>, "catalin.marinas@armm.com" <catalin.marinas@armm.com>, "mark.rutland@arm.com" <mark.rutland@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>, "olaf@aepfle.de" <olaf@aepfle.de>, "apw@canonical.com" <apw@canonical.com>, "jasowang@redhat.com" <jasowang@redhat.com>, Stephen Hemminger <sthemmin@microsoft.com>, vkuznets <vkuznets@redhat.com> Subject: RE: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor Date: Fri, 4 Jan 2019 20:05:10 +0000 [thread overview] Message-ID: <CY4PR21MB077301ECE13325F8C75EE941D78E0@CY4PR21MB0773.namprd21.prod.outlook.com> (raw) In-Reply-To: <e0374a07-809c-cabd-2eb6-e6b5ad84742e@arm.com> From: Marc Zyngier <marc.zyngier@arm.com> Sent: Thursday, December 13, 2018 3:23 AM > >> As Will said, this isn't a viable option. Please follow SMCCC 1.1. > > > > I'll have to start a conversation with the Hyper-V team about this. > > I don't know why they chose to use HVC #1 or this register scheme > > for output values. It may be tough to change at this point because > > there are Windows guests on Hyper-V for ARM64 that are already > > using this approach. > > I appreciate you already have stuff in the wild, but there is definitely > a case to be made for supporting architecturally specified mechanisms in > a hypervisor, and SMCCC is definitely part of it (I'm certainly curious > of how you support the Spectre mitigation otherwise). > The Hyper-V guys I need to discuss this with are not back from the holidays until January 7th. I'll follow up on this thread once I've had that conversation. > >>> +static int hv_cpu_init(unsigned int cpu) > >>> +{ > >>> + u64 msr_vp_index; > >>> + > >>> + hv_get_vp_index(msr_vp_index); > >>> + > >>> + hv_vp_index[smp_processor_id()] = msr_vp_index; > >>> + > >>> + if (msr_vp_index > hv_max_vp_index) > >>> + hv_max_vp_index = msr_vp_index; > >>> + > >>> + return 0; > >>> +} > >> > >> Is that some new way to describe a CPU topology? If so, why isn't that > >> exposed via the ACPI tables that the kernel already parses? > > > > Hyper-V's hypercall interface uses vCPU identifiers that are not > > guaranteed to be consecutive integers or to match what ACPI shows. > > No topology information is implied -- it's just unique identifiers. The > > hv_vp_index array provides easy mapping from Linux's consecutive > > integer IDs for CPUs when needed to construct hypercall arguments. > > That's extremely odd. The hypervisor obviously knows which vCPU is doing > a hypercall, and if referencing another vCPU, the virtualized MPIDR_EL1 > value should be used. I don't think deviating from the architecture is a > good idea (but I appreciate this is none of your doing). Following the > architecture would allow this code to directly use the cpu_logical_map > infrastructure we already have. I see what you are getting at. However, some Hyper-V hypercalls allow specifying arbitrary sets of vCPUs. These hypercalls are used to define target processors in the virtual PCI code (which I have not yet brought over to ARM64) and in enlightenments for IPIs and TLB flushes (used by Windows guests and Linux guests on x86, but not yet brought over to Linux ARM64, if they ever will be). These hypercalls take bitmaps as arguments, similar to a Linux cpumask, as defined in Sections 7.8.7.3 thru 7.8.7.5 in the Hyper-V TLFS. So Hyper-V defines its own VP index that is akin to the index into the cpu_logical_map, though it may not be the same mapping. My earlier comments may have been misleading -- the Hyper-V VP index is an integer ranging from 0 thru (# vCPUs - 1). With these requirements, Hyper-V defining its own VP index seems like a reasonable thing to do. And since Hyper-V provides the same hypercall interfaces for both x86 and ARM64 implementations, and for Windows guests, there's not much choice but to use the Hyper-V VP index as specified. Michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-04 20:05 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-22 3:09 [PATCH 0/4] Hyper-V: Enable Linux guests on Hyper-V on ARM64 kys 2018-11-22 3:09 ` kys at linuxonhyperv.com 2018-11-22 3:10 ` [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-22 3:10 ` [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:19 ` Greg KH 2018-11-26 19:19 ` Greg KH 2018-12-07 13:42 ` Will Deacon 2018-12-07 13:42 ` Will Deacon 2018-12-07 14:43 ` Marc Zyngier 2018-12-07 14:43 ` Marc Zyngier 2018-12-12 5:00 ` Michael Kelley 2018-12-12 5:00 ` Michael Kelley 2018-12-13 11:23 ` Marc Zyngier 2018-12-13 11:23 ` Marc Zyngier 2019-01-04 20:05 ` Michael Kelley [this message] 2019-01-04 20:05 ` Michael Kelley 2019-01-21 4:38 ` Michael Kelley 2019-01-21 4:38 ` Michael Kelley 2018-11-22 3:10 ` [PATCH 3/4] Drivers: hv: vmbus: Add hooks for per-CPU IRQ kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:21 ` Greg KH 2018-11-26 19:21 ` Greg KH 2018-11-26 19:47 ` Michael Kelley 2018-11-26 19:47 ` Michael Kelley 2018-11-26 19:57 ` Greg KH 2018-11-26 19:57 ` Greg KH 2018-11-26 20:56 ` Michael Kelley 2018-11-26 20:56 ` Michael Kelley 2018-11-27 6:20 ` Greg KH 2018-11-27 6:20 ` Greg KH 2018-11-27 10:19 ` Will Deacon 2018-11-27 10:19 ` Will Deacon 2018-12-03 1:47 ` Michael Kelley 2018-12-03 1:47 ` Michael Kelley 2018-11-22 3:10 ` [PATCH 4/4] Drivers: hv: Enable CONFIG_HYPERV on ARM64 kys 2018-11-22 3:10 ` kys at linuxonhyperv.com 2018-11-26 19:18 ` [PATCH 1/4] arm64: hyperv: Add core Hyper-V include files Greg KH 2018-11-26 19:18 ` Greg KH 2018-11-26 20:21 ` Joshua R. Poulson 2018-11-26 20:21 ` Joshua R. Poulson 2018-11-27 3:06 ` KY Srinivasan 2018-11-27 3:06 ` KY Srinivasan 2018-12-07 13:42 ` Will Deacon 2018-12-07 13:42 ` Will Deacon 2018-12-12 1:19 ` Michael Kelley 2018-12-12 1:19 ` Michael Kelley 2018-12-10 17:43 ` Vitaly Kuznetsov 2018-12-10 17:43 ` Vitaly Kuznetsov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CY4PR21MB077301ECE13325F8C75EE941D78E0@CY4PR21MB0773.namprd21.prod.outlook.com \ --to=mikelley@microsoft.com \ --cc=apw@canonical.com \ --cc=catalin.marinas@armm.com \ --cc=devel@linuxdriverproject.org \ --cc=gregkh@linuxfoundation.org \ --cc=jasowang@redhat.com \ --cc=kys@microsoft.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=olaf@aepfle.de \ --cc=sthemmin@microsoft.com \ --cc=vkuznets@redhat.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.