From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 72F83306B3D; Wed, 15 Jul 2026 16:32:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784133126; cv=none; b=OhCr4taIzqAg0nCUhUPaaIHergLoRA2GzKAmFPxUJPKq4IkOdBTB4DLyP1wjFf/sjjNZwzHDT05v/ABoe8TDGIgPJoqs76sBjGoGfAWRQf9VkZ9gPSNwYIVHa/E8R001B1FG0DEvWoSwNyDDunnuulzAfhbVrXAU7dTxuhKtOBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784133126; c=relaxed/simple; bh=YEfGwbfCCDQLg/NWb7ORac95kV+EGg+EboFB0vctntM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rXWZ/MW2IjSR2NbjyABklZHwazJ33VDkcE4ePMQYYd8v2xVt7hT88AUaAa+AWu45G6LI5ueIsMHJXvuf2OsFMq5utsNSqU5jXOHEwi3FIJFt7h7kK5g2qGAn09pb9zqnXUSaGyy3lfX+HwlMQ7983AkcBAqKa+9fzEEsyskXcMs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=EsnnfkBL; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="EsnnfkBL" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 84252152B; Wed, 15 Jul 2026 09:31:59 -0700 (PDT) Received: from [10.1.25.27] (e122027.cambridge.arm.com [10.1.25.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AAAE93F7B4; Wed, 15 Jul 2026 09:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784133123; bh=YEfGwbfCCDQLg/NWb7ORac95kV+EGg+EboFB0vctntM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=EsnnfkBLkUlVpcHHNTfvAfYqDrvm/mannNNibJNPyWFan+lyzGNnEwYw7RTUJaujr mT44hxReEcWVNie5MDgDs9a2HVsuOkycUohPyMHxstT0Dq9sC532UfxFDx7wpnkO4I 0oNFw4lnqb0uYKfNqSDRuJKCtEOW9eIH2Ueclun8= Message-ID: Date: Wed, 15 Jul 2026 17:31:57 +0100 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 26/37] KVM: arm64: WARN on injected undef exceptions To: Marc Zyngier Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve , WeiLin.Chang@arm.com, Lorenzo Pieralisi References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-27-steven.price@arm.com> <8733xk5k7v.wl-maz@kernel.org> <87y0fc43ut.wl-maz@kernel.org> From: Steven Price Content-Language: en-GB In-Reply-To: <87y0fc43ut.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15/07/2026 17:25, Marc Zyngier wrote: > On Wed, 15 Jul 2026 17:15:31 +0100, > Steven Price wrote: >> >> On 15/07/2026 16:46, Marc Zyngier wrote: >>> On Wed, 15 Jul 2026 15:28:28 +0100, >>> Steven Price 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 >>>> Reviewed-by: Gavin Shan >>>> Reviewed-by: Suzuki K Poulose >>>> --- >>>> 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 guest which triggers this as dead. Would a KVM_BUG() be more appropriate here? Thanks, Steve