RE: [PATCH v5 2/8] arm64: hyperv: Add hypercall and register access functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Marc Zyngier <maz@xxxxxxxxxx> Sent: Thursday, November 7, 2019 1:11 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.

The "undisclosed reason" is performance.  Hyper-V implements 100+
different hypercalls, though many are used only by code in the
parent partition (dom0 in Xen terminology).  These hypercalls
often take moderately complex data structures as inputs and outputs.
While the data structures can be passed by reference using the
guest physical address (GPA), Hyper-V also offers a "fast" option
where both input and output data structures are passed entirely in
registers, avoiding two virt_to_phys() calls to get GPAs.  The
Hyper-V calling sequence allows X0-X16 to be used for input and output
data for these "fast" hypercalls, allowing more hypercalls to fit in
registers vs. the SMCCC that is limited to X1-X6.  The "fast" hypercall
approach originated with Hyper-V on x86/x64, where it also uses
most of the available registers.

These initial Linux patches for ARM64 make only a limited number of
hypercalls, all of which fit in X0-X6, even in "fast" mode.  So the
"why" of the Hyper-V calling sequence is certainly not evident.
But future Hyper-V enlightenments in Linux on ARM64 will use
more hypercalls, some of which would not be able to use "fast" mode
with the SMCCC register limits.

> 
> 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.

The Hyper-V team has agreed to look at the implications of adding a
shim to accept hypercalls through HVC #0 that follow the SMCCC.  I'll
follow up once we have a better sense of what Hyper-V can do, and
the perf implications.

Michael
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux