On Thu, 18 May 2023 10:08:46 +0100, Salil Mehta <salil.mehta@xxxxxxxxxx> wrote: > > Hi Marc, > > > From: Marc Zyngier <maz@xxxxxxxxxx> > > Sent: Thursday, May 18, 2023 9:06 AM > > To: Oliver Upton <oliver.upton@xxxxxxxxx> > > Cc: Salil Mehta <salil.mehta@xxxxxxxxxx>; 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 > > > > On Wed, 17 May 2023 19:38:14 +0100, > > Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > > > > > Hi Salil, > > > > > > On Wed, May 17, 2023 at 06:00:18PM +0000, Salil Mehta wrote: > > > > > > [...] > > > > > > > > > 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. 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? Thanks, M. -- Without deviation from the norm, progress is not possible.
