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 08C451D4609; Thu, 17 Oct 2024 11:59:10 +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=1729166355; cv=none; b=eSaVHB4aXLOe454pSMufAouHpB0WoElfW1FFxv38p5jstUpxgkr4j5afryUpiknbTt63O7DUwDHB1XrRTSMxoceMvIBTmh0Oq7DZhqTkUNNdEt7PTf5ywz+zk4A5tQznezJAwpfU8hdP3IHXDbG4hV7pLjcFrPwr8xk8JeA7TEc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729166355; c=relaxed/simple; bh=KVx90sJAya4fJeJB1T9VQH8syX+5Y2Dms8kUeU21dyw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=G4lvZS5vqBjrjtYmpGwDVknhSgDst2ZDREDvIFsruGlFPfLNYmrU8f0HQksVakTnSXY5kuHZ+k1SVF5ADjEcALL2vQfdCjrK9+Kt4AVkF8GoZVmcz8JCl71IUrv5OiVpUkXbIHOV/VNUgaVlbNWAdOBppbTEaooI0yW/06Mg6lY= 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; 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 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 D1DF1FEC; Thu, 17 Oct 2024 04:59:39 -0700 (PDT) Received: from [10.57.22.188] (unknown [10.57.22.188]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5CE593F71E; Thu, 17 Oct 2024 04:59:07 -0700 (PDT) Message-ID: <710c066e-75fa-4f12-b27a-c8948d02bb4b@arm.com> Date: Thu, 17 Oct 2024 12:59:06 +0100 Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 19/43] KVM: arm64: Handle realm MMIO emulation Content-Language: en-GB To: Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , 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" References: <20241004152804.72508-1-steven.price@arm.com> <20241004152804.72508-20-steven.price@arm.com> From: Suzuki K Poulose In-Reply-To: <20241004152804.72508-20-steven.price@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/10/2024 16:27, Steven Price wrote: > MMIO emulation for a realm cannot be done directly with the VM's > registers as they are protected from the host. However, for emulatable > data aborts, the RMM uses GPRS[0] to provide the read/written value. > We can transfer this from/to the equivalent VCPU's register entry and > then depend on the generic MMIO handling code in KVM. > > For a MMIO read, the value is placed in the shared RecExit structure > during kvm_handle_mmio_return() rather than in the VCPU's register > entry. > > Signed-off-by: Steven Price > --- > v3: Adapt to previous patch changes > --- > arch/arm64/kvm/mmio.c | 10 +++++++++- > arch/arm64/kvm/rme-exit.c | 6 ++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c > index cd6b7b83e2c3..66a838b3776a 100644 > --- a/arch/arm64/kvm/mmio.c > +++ b/arch/arm64/kvm/mmio.c > @@ -6,6 +6,7 @@ > > #include > #include > +#include > #include > > #include "trace.h" > @@ -90,6 +91,9 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) > > vcpu->mmio_needed = 0; > > + if (vcpu_is_rec(vcpu)) > + vcpu->arch.rec.run->enter.flags |= REC_ENTER_EMULATED_MMIO; > + > if (!kvm_vcpu_dabt_iswrite(vcpu)) { > struct kvm_run *run = vcpu->run; Should we additionally handle injecting an abort if there was no valid syndrome information ? Like we do for protected VMs and normal VMs when userspace doesn't offer to help ? > > @@ -108,7 +112,11 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) > trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr, > &data); > data = vcpu_data_host_to_guest(vcpu, data, len); > - vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data); > + > + if (vcpu_is_rec(vcpu)) > + vcpu->arch.rec.run->enter.gprs[0] = data; I wonder if we can skip this here and we can sync the "enter.gprs[]" from vcpu state at rec_enter, similar to what we do for PSCI/HOST call exits. Also the ESR_ELx_SRT is always x0 for a Realm exit. So, we should always find the enter.gpr[0] in vcpu.regs[0] at rec_enter. Suzuki > + else > + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data); > } > > /* > diff --git a/arch/arm64/kvm/rme-exit.c b/arch/arm64/kvm/rme-exit.c > index e96ea308212c..1ddbff123149 100644 > --- a/arch/arm64/kvm/rme-exit.c > +++ b/arch/arm64/kvm/rme-exit.c > @@ -25,6 +25,12 @@ static int rec_exit_reason_notimpl(struct kvm_vcpu *vcpu) > > static int rec_exit_sync_dabt(struct kvm_vcpu *vcpu) > { > + struct realm_rec *rec = &vcpu->arch.rec; > + > + if (kvm_vcpu_dabt_iswrite(vcpu) && kvm_vcpu_dabt_isvalid(vcpu)) > + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), > + rec->run->exit.gprs[0]); > + > return kvm_handle_guest_abort(vcpu); > } >