On 10/13/20 12:51, James Morse wrote: > Hi Marc, > > On 13/10/2020 11:32, Marc Zyngier wrote: > > On 2020-10-12 16:32, James Morse wrote: > >> On 09/10/2020 13:48, Qais Yousef wrote: > >>> On 10/09/20 13:34, Marc Zyngier wrote: > >>>> You can try setting vcpu->arch.target to -1, which is already caught by > >>>> kvm_vcpu_initialized() right at the top of this function. This will > >> > >>>> prevent any reentry unless the VMM issues a KVM_ARM_VCPU_INIT ioctl. > >> > >> This doesn't reset SPSR, so this lets the VMM restart the guest with a > >> bad value. > > > > That's not my reading of the code. Without a valid target, you cannot enter > > the guest (kvm_vcpu_initialized() prevents you to do so). To set the target, > > you need to issue a KVM_ARM_VCPU_INIT ioctl, which eventually calls > > > kvm_reset_vcpu(), which does set PSTATE to something legal. > > aha! So it does, this is what I was missing. > > > > Or do you mean the guest's SPSR_EL1? Why would that matter? > > > >> I think we should make it impossible to return to aarch32 from EL2 on > >> these systems. > > > > And I'm saying that the above fulfills that requirement. Am I missing > > something obvious? > > Nope, I was. > > I agree the check on entry from user-space isn't needed. Thanks both. So using the vcpu->arch.target = -1 is the best way forward. In my experiments when I did that I considered calling kvm_reset_vcpu() too, does it make sense to force the reset here too? Or too heavy handed? Thanks -- Qais Yousef
