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
