[<prev] [next>] [day] [month] [year] [list]
Message-ID: <c8403255bf874856c10f07189e27080a@www.loen.fr>
Date: Thu, 07 Nov 2019 10:19:56 +0109
From: Marc Zyngier <maz@...nel.org>
To: Michael Kelley <mikelley@...rosoft.com>
Cc: <will@...nel.org>, <catalin.marinas@....com>,
<mark.rutland@....com>, <linux-arm-kernel@...ts.infradead.org>,
<gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>,
<linux-hyperv@...r.kernel.org>, <devel@...uxdriverproject.org>,
<olaf@...fle.de>, <apw@...onical.com>,
vkuznets <vkuznets@...hat.com>, <jasowang@...hat.com>,
<marcelo.cerri@...onical.com>, KY Srinivasan <kys@...rosoft.com>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
"boqun.feng" <boqun.feng@...il.com>
Subject: RE: [PATCH v5 2/8] arm64: hyperv: Add hypercall and register access functions
On 2019-11-06 19:08, Michael Kelley wrote:
> From: Marc Zyngier <maz@...nel.org> Sent: Wednesday, November 6,
> 2019 2:20 AM
>>
>> On 2019-10-03 20:12, Michael Kelley wrote:
>> > Add ARM64-specific code to make Hyper-V hypercalls and to
>> > access virtual processor synthetic registers via hypercalls.
>> > Hypercalls use a Hyper-V specific calling sequence with a non-zero
>> > immediate value per Section 2.9 of the SMC Calling Convention
>> > spec.
>>
>> I find this "following the spec by actively sidestepping it" counter
>> productive. You (or rather the Hyper-V people) are reinventing the
>> wheel (of the slightly square variety) instead of using the standard
>> that the whole of the ARM ecosystem seems happy to take advantage
>> of.
>>
>> I wonder what is the rational for this. If something doesn't quite
>> work for Hyper-V, I think we'd all like to know.
>>
>
> I'll go another round internally with the Hyper-V people on this
> topic and impress upon them the desire of the Linux community to
> have Hyper-V adopt the true spirit of the spec. But I know they are
> fairly set in their approach at this point, regardless of the
> technical
> merits or lack thereof. Hyper-V is shipping and in use as a
> commercial
> product on ARM64 hardware, which makes it harder to change. I
> hope we can find a way to avoid a complete impasse ....
Hyper-V shipping with their own calling convention is fine by me. Linux
having to implement multiple calling conventions because the Hyper-V
folks refuse (for undisclosed reason) to adopt the standard isn't fine
at
all.
HV can perfectly retain its interface for Windows or other things, but
please *at least* implement the standard interface on which all
existing
operating systems rely.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists