Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions

[Steven Price]

On 15/07/2026 17:43, Marc Zyngier wrote:
> On Wed, 15 Jul 2026 17:31:57 +0100,
> Steven Price <steven.price@xxxxxxx> wrote:
>>
>> On 15/07/2026 17:25, Marc Zyngier wrote:
>>> On Wed, 15 Jul 2026 17:15:31 +0100,
>>> Steven Price <steven.price@xxxxxxx> wrote:
>>>>
>>>> On 15/07/2026 16:46, Marc Zyngier wrote:
>>>>> On Wed, 15 Jul 2026 15:28:28 +0100,
>>>>> Steven Price <steven.price@xxxxxxx> wrote:
>>>>>>
>>>>>> The RMM doesn't allow injection of a undefined exception into a realm
>>>>>> guest. Add a WARN to catch if this ever happens.
>>>>>>
>>>>>> Signed-off-by: Steven Price <steven.price@xxxxxxx>
>>>>>> Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
>>>>>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
>>>>>> ---
>>>>>> Changes since v6:
>>>>>>  * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)!
>>>>>> ---
>>>>>>  arch/arm64/kvm/inject_fault.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>>>>>> index 6492397b73d7..613f223bc7a3 100644
>>>>>> --- a/arch/arm64/kvm/inject_fault.c
>>>>>> +++ b/arch/arm64/kvm/inject_fault.c
>>>>>> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu)
>>>>>>   */
>>>>>>  void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>>>>>>  {
>>>>>> +	WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC");
>>>>>>  	if (vcpu_el1_is_32bit(vcpu))
>>>>>>  		inject_undef32(vcpu);
>>>>>>  	else
>>>>>
>>>>> No. WARN_ONCE at a push, but even then, this looks dodgy.
>>>>
>>>> Yep WARN_ONCE() would be better. This function should never be called
>>>> for a realm guest.
>>>>
>>>>> Exceptions must be injectable. Otherwise, how do you respond to, for
>>>>> example, a sysreg access for a feature that is hidden from the guest?
>>>>
>>>> The RMM doesn't allow the host to inject exceptions - with the exception
>>>> of SEA after a host-emulated MMIO.
>>>>
>>>>> Will the RMM perform this in KVM's stead?
>>>>
>>>> Yes the RMM would have to handle this for the likes of sysreg accesses.
>>>> The host doesn't control the trapping of sysreg accesses. There are a
>>>> few GIC-related registers which are forwarded to the host ("REC exit due
>>>> to system register access") but generally the handling of sysregs is
>>>> entirely internal to the RMM.
>>>
>>> Then the only option is not to just warn, but to mark all realms as
>>> dead and refuse to run them any further. If we can't inject an
>>> exception and that the RMM isn't doing its job, I can't see how we can
>>> continue at all.
>>
>> You've got a point - I'm not sure whether it's entirely reasonable to
>> refuse to run any realm, but it certainly would be sensible to mark the
> 
> If the RMM is not playing ball by not doing its part of the bargain,
> the only sane option is stop talking to it immediately. Who knows what
> else the implementation got wrong?

If the RMM isn't playing ball then we're in trouble whatever. Refusing
to talk to the RMM ensures that we wouldn't be able to reclaim any of
the memory that has been donated to the guest (or related RMM metadata).
It also doesn't rule out that a faulty RMM has left a minefield of
"delegated" memory which could cause a GPF at any moment. In reality the
only "safe" option is to BUG() the kernel and completely give up.

But the chances are that the RMM hasn't suddenly become malicious, and
in most likely the situation is that we've hit a corner case which in
the RMM which is highly likely to only affect the one guest.
"panic_on_warn" is available for those who would prefer the system to
stop in these situations.

And of course it's entirely possible that the bug is in Linux and the
RMM is playing ball it's just that I've screwed something up. In which
case the realm VM is probably screwed, but the rest of the system
(including other guests) should be absolutely fine.

I can of course code up a "rmm_is_bugged" flag and litter the code with
paths to handle that - but I can't imagine that's actually what you
want. Although please do let me know if I'm wrong, I seem to have
misplaced my mind reading hat ;)

>> guest which triggers this as dead. Would a KVM_BUG() be more appropriate
>> here?
> 
> That's the absolutely minimal option. Not necessarily the safe one.

I'm not sure how to make it "safer" - I don't think there is a
completely "safe" option for this "should never happen" case.

Thanks,
Steve