Hi Marc, > From: Marc Zyngier <maz@xxxxxxxxxx> > Sent: Thursday, May 18, 2023 10:43 AM > To: Salil Mehta <salil.mehta@xxxxxxxxxx> > Cc: Oliver Upton <oliver.upton@xxxxxxxxx>; kvmarm@xxxxxxxxxxxxxxx; > kvm@xxxxxxxxxxxxxxx; Paolo Bonzini <pbonzini@xxxxxxxxxx>; James Morse > <james.morse@xxxxxxx>; Suzuki K Poulose <suzuki.poulose@xxxxxxx>; yuzenghui > <yuzenghui@xxxxxxxxxx>; Sean Christopherson <seanjc@xxxxxxxxxx> > Subject: Re: [PATCH v3 08/13] KVM: arm64: Add support for > KVM_EXIT_HYPERCALL > [...] > > > > > > > Should we expose the ESR, or at least ESR_EL2.IL as an additional > > > > > > > flag? > > > > > > > > > > > > > > > I think we would need "Immediate value" of the ESR_EL2 register in the > > > > > user-space/VMM to be able to construct the syndrome value. I cannot see > > > > > where it is being sent? > > > > > > > > The immediate value is not exposed to userspace, although by definition > > > > the immediate value must be zero. The SMCCC spec requires all compliant > > > > calls to use an immediate of zero (DEN0028E 2.9). > > > > > > > > Is there a legitimate use case for hypercalls with a nonzero immediate? > > > > They would no longer be considered SMCCC calls at that point, so they > > > > wouldn't work with the new UAPI. > > > > > > I agree. The use of non-zero immediate has long been deprecated. I > > > guess we should actually reject non-zero immediate for HVC just like > > > we do for SMC. > > > > > > Ok. Maybe I will hard code Immediate value as 0 to create a syndrome value > > at the VMM/Qemu and will also put a note stating non-zero immediate for > > HVC/SVC are not supported/deprecated. > > Yes, because this should be the only situation where you should see > such an exit to userspace. > > > > If there is an actual need for a non-zero immediate to be propagated > > > to userspace (want to emulate Xen's infamous 'HVC #0xEA1'?), then this > > > should be an extension to the current API. > > > > Oh ok, then perhaps this new extension change should be simultaneously > > committed to avoid breaking Xen? > > How would that break Xen? I don't have any plan to emulate Xen in any > shape or form, and I don't think anyone want to do that in userspace > either. Ok. I thought you are suggestion an exception which is already in use and the current change might break it but now that does not seems to be the case. > I really want to see an actual use case to expand this stuff. Because > so far, we follow the strict SMCCC spec, and nothing else. But if we > admit deviations, do we also have to expose SMC and HVC as different > instructions? Ok got it. No problem and makes sense what you just said. Maybe in future if it is really required then we can always come back to it. For now, I will go ahead with the agreed change in the qemu. Many thanks Salil.
