On 2020-10-13 12:59, Qais Yousef wrote:
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?
No, userspace should know about it and take action if it wants too.
Trying to fix it behind the scenes is setting expectations, which
I'd really like to avoid.
M.
--
Jazz is not dead. It just smells funny...
