From: Michael Kelley Sent: Friday, January 4, 2019 12:05 PM > > > >> 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. > Feedback from the Hyper-V guys is that they believe the Hyper-V specific hypercall sequence *is* compliant with SMCCC 1.1, in the sense of being outside the requirements per Section 2.9 since the Hyper-V hypercall sequence uses HVC #1. Hyper-V wanted to use a simpler calling sequence that doesn't have the full register save/restore requirements, for better performance. The details of the Hyper-V hypercall sequence are documented internally, but we do still need to get it published externally as part of a Hyper-V TLFS version that includes ARM64. Hyper-V uses the full SMC Calling Conventions in other places, such as for PSCI calls, for SMCs to EL3, and for the Spectre mitigation related calls. Michael _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
