From: Will Deacon <will@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>,
Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Sebastian Ene <sebastianene@google.com>,
Fuad Tabba <tabba@google.com>,
kvmarm@lists.linux.dev, kernel-team@android.com
Subject: [PATCH v2 07/10] KVM: arm64: Handle FFA_MEM_RECLAIM calls from the host
Date: Wed, 19 Apr 2023 13:20:48 +0100 [thread overview]
Message-ID: <20230419122051.1341-8-will@kernel.org> (raw)
In-Reply-To: <20230419122051.1341-1-will@kernel.org>
Intecept FFA_MEM_RECLAIM calls from the host and transition the host
stage-2 page-table entries from the SHARED_OWNED state back to the OWNED
state once EL3 has confirmed that the secure mapping has been reclaimed.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 79 +++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 95bc70e52e91..b23e3869ce63 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -124,6 +124,23 @@ static void spmd_mem_share(struct arm_smccc_res *res, u32 len, u32 fraglen)
res);
}
+static void spmd_mem_reclaim(struct arm_smccc_res *res, u32 handle_lo,
+ u32 handle_hi, u32 flags)
+{
+ arm_smccc_1_1_smc(FFA_MEM_RECLAIM,
+ handle_lo, handle_hi, flags,
+ 0, 0, 0, 0,
+ res);
+}
+
+static void spmd_retrieve_req(struct arm_smccc_res *res, u32 len)
+{
+ arm_smccc_1_1_smc(FFA_FN64_MEM_RETRIEVE_REQ,
+ len, len,
+ 0, 0, 0, 0, 0,
+ res);
+}
+
static void do_ffa_rxtx_map(struct arm_smccc_res *res,
struct kvm_cpu_context *ctxt)
{
@@ -375,6 +392,65 @@ static void do_ffa_mem_share(struct arm_smccc_res *res,
return;
}
+static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, handle_lo, ctxt, 1);
+ DECLARE_REG(u32, handle_hi, ctxt, 2);
+ DECLARE_REG(u32, flags, ctxt, 3);
+ struct ffa_composite_mem_region *reg;
+ struct ffa_mem_region *buf;
+ int ret = 0;
+ u32 offset;
+ u64 handle;
+
+ handle = PACK_HANDLE(handle_lo, handle_hi);
+
+ hyp_spin_lock(&host_buffers.lock);
+
+ buf = hyp_buffers.tx;
+ *buf = (struct ffa_mem_region) {
+ .sender_id = HOST_FFA_ID,
+ .handle = handle,
+ };
+
+ spmd_retrieve_req(res, sizeof(*buf));
+ buf = hyp_buffers.rx;
+ if (res->a0 != FFA_MEM_RETRIEVE_RESP)
+ goto out_unlock;
+
+ /* Check for fragmentation */
+ if (res->a1 != res->a2) {
+ ret = FFA_RET_ABORTED;
+ goto out_unlock;
+ }
+
+ offset = buf->ep_mem_access[0].composite_off;
+ /*
+ * We can trust the SPMD to get this right, but let's at least
+ * check that we end up with something that doesn't look _completely_
+ * bogus.
+ */
+ if (WARN_ON(offset > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
+ ret = FFA_RET_ABORTED;
+ goto out_unlock;
+ }
+
+ reg = (void *)buf + offset;
+ spmd_mem_reclaim(res, handle_lo, handle_hi, flags);
+ if (res->a0 != FFA_SUCCESS)
+ goto out_unlock;
+
+ /* If the SPMD was happy, then we should be too. */
+ WARN_ON(ffa_host_unshare_ranges(reg->constituents,
+ reg->addr_range_cnt));
+out_unlock:
+ hyp_spin_unlock(&host_buffers.lock);
+
+ if (ret)
+ ffa_to_smccc_res(res, ret);
+}
+
/*
* Is a given FFA function supported, either by forwarding on directly
* or by handling at EL2?
@@ -428,6 +504,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
case FFA_FN64_MEM_SHARE:
do_ffa_mem_share(&res, host_ctxt);
goto out_handled;
+ case FFA_MEM_RECLAIM:
+ do_ffa_mem_reclaim(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.40.0.634.g4ca3ef3211-goog
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>,
Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Sebastian Ene <sebastianene@google.com>,
Fuad Tabba <tabba@google.com>,
kvmarm@lists.linux.dev, kernel-team@android.com
Subject: [PATCH v2 07/10] KVM: arm64: Handle FFA_MEM_RECLAIM calls from the host
Date: Wed, 19 Apr 2023 13:20:48 +0100 [thread overview]
Message-ID: <20230419122051.1341-8-will@kernel.org> (raw)
In-Reply-To: <20230419122051.1341-1-will@kernel.org>
Intecept FFA_MEM_RECLAIM calls from the host and transition the host
stage-2 page-table entries from the SHARED_OWNED state back to the OWNED
state once EL3 has confirmed that the secure mapping has been reclaimed.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/hyp/nvhe/ffa.c | 79 +++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
index 95bc70e52e91..b23e3869ce63 100644
--- a/arch/arm64/kvm/hyp/nvhe/ffa.c
+++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
@@ -124,6 +124,23 @@ static void spmd_mem_share(struct arm_smccc_res *res, u32 len, u32 fraglen)
res);
}
+static void spmd_mem_reclaim(struct arm_smccc_res *res, u32 handle_lo,
+ u32 handle_hi, u32 flags)
+{
+ arm_smccc_1_1_smc(FFA_MEM_RECLAIM,
+ handle_lo, handle_hi, flags,
+ 0, 0, 0, 0,
+ res);
+}
+
+static void spmd_retrieve_req(struct arm_smccc_res *res, u32 len)
+{
+ arm_smccc_1_1_smc(FFA_FN64_MEM_RETRIEVE_REQ,
+ len, len,
+ 0, 0, 0, 0, 0,
+ res);
+}
+
static void do_ffa_rxtx_map(struct arm_smccc_res *res,
struct kvm_cpu_context *ctxt)
{
@@ -375,6 +392,65 @@ static void do_ffa_mem_share(struct arm_smccc_res *res,
return;
}
+static void do_ffa_mem_reclaim(struct arm_smccc_res *res,
+ struct kvm_cpu_context *ctxt)
+{
+ DECLARE_REG(u32, handle_lo, ctxt, 1);
+ DECLARE_REG(u32, handle_hi, ctxt, 2);
+ DECLARE_REG(u32, flags, ctxt, 3);
+ struct ffa_composite_mem_region *reg;
+ struct ffa_mem_region *buf;
+ int ret = 0;
+ u32 offset;
+ u64 handle;
+
+ handle = PACK_HANDLE(handle_lo, handle_hi);
+
+ hyp_spin_lock(&host_buffers.lock);
+
+ buf = hyp_buffers.tx;
+ *buf = (struct ffa_mem_region) {
+ .sender_id = HOST_FFA_ID,
+ .handle = handle,
+ };
+
+ spmd_retrieve_req(res, sizeof(*buf));
+ buf = hyp_buffers.rx;
+ if (res->a0 != FFA_MEM_RETRIEVE_RESP)
+ goto out_unlock;
+
+ /* Check for fragmentation */
+ if (res->a1 != res->a2) {
+ ret = FFA_RET_ABORTED;
+ goto out_unlock;
+ }
+
+ offset = buf->ep_mem_access[0].composite_off;
+ /*
+ * We can trust the SPMD to get this right, but let's at least
+ * check that we end up with something that doesn't look _completely_
+ * bogus.
+ */
+ if (WARN_ON(offset > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
+ ret = FFA_RET_ABORTED;
+ goto out_unlock;
+ }
+
+ reg = (void *)buf + offset;
+ spmd_mem_reclaim(res, handle_lo, handle_hi, flags);
+ if (res->a0 != FFA_SUCCESS)
+ goto out_unlock;
+
+ /* If the SPMD was happy, then we should be too. */
+ WARN_ON(ffa_host_unshare_ranges(reg->constituents,
+ reg->addr_range_cnt));
+out_unlock:
+ hyp_spin_unlock(&host_buffers.lock);
+
+ if (ret)
+ ffa_to_smccc_res(res, ret);
+}
+
/*
* Is a given FFA function supported, either by forwarding on directly
* or by handling at EL2?
@@ -428,6 +504,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt)
case FFA_FN64_MEM_SHARE:
do_ffa_mem_share(&res, host_ctxt);
goto out_handled;
+ case FFA_MEM_RECLAIM:
+ do_ffa_mem_reclaim(&res, host_ctxt);
+ goto out_handled;
}
if (ffa_call_supported(func_id))
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-19 12:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 12:20 [PATCH v2 00/10] KVM: arm64: FF-A proxy for pKVM Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 01/10] KVM: arm64: Block unsafe FF-A calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-05-10 19:08 ` Oliver Upton
2023-05-22 11:22 ` Will Deacon
2023-05-22 11:22 ` Will Deacon
2023-05-23 8:07 ` Oliver Upton
2023-05-23 8:07 ` Oliver Upton
2023-04-19 12:20 ` [PATCH v2 02/10] KVM: arm64: Probe FF-A version and host/hyp partition ID during init Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 03/10] KVM: arm64: Allocate pages for hypervisor FF-A mailboxes Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 04/10] KVM: arm64: Handle FFA_RXTX_MAP and FFA_RXTX_UNMAP calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-05-10 20:50 ` Oliver Upton
2023-05-22 11:48 ` Will Deacon
2023-05-22 11:48 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 05/10] KVM: arm64: Add FF-A helpers to share/unshare memory with secure world Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 06/10] KVM: arm64: Handle FFA_MEM_SHARE calls from the host Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` Will Deacon [this message]
2023-04-19 12:20 ` [PATCH v2 07/10] KVM: arm64: Handle FFA_MEM_RECLAIM " Will Deacon
2023-04-19 12:20 ` [PATCH v2 08/10] KVM: arm64: Handle FFA_MEM_LEND " Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 09/10] KVM: arm64: Handle FFA_FEATURES call " Will Deacon
2023-04-19 12:20 ` Will Deacon
2023-04-19 12:20 ` [PATCH v2 10/10] KVM: arm64: pkvm: Add support for fragmented FF-A descriptors Will Deacon
2023-04-19 12:20 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230419122051.1341-8-will@kernel.org \
--to=will@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=james.morse@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=sebastianene@google.com \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.