Thread (59 messages) 59 messages, 9 authors, 2023-09-13

Re: [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace

From: Marc Zyngier <maz@kernel.org>
Date: 2023-02-07 11:23:53
Also in: kvm, kvmarm, linux-acpi, linux-arch, linux-pm, lkml, loongarch

On Tue, 07 Feb 2023 09:41:54 +0000,
Suzuki K Poulose [off-list ref] wrote:
Hi Marc,

On 06/02/2023 12:31, Marc Zyngier wrote:
quoted
On Mon, 06 Feb 2023 10:10:41 +0000,
Suzuki K Poulose [off-list ref] wrote:
quoted
This may not be always possible, e.g., for Realms. GET_ONE_REG is
not supported. So using an explicit passing down of the args is
preferrable.
What is the blocker for CCA to use GET_ONE_REG? The value obviously
exists and is made available to the host. pKVM is perfectly able to
use GET_ONE_REG and gets a bunch of zeroes for things that the
hypervisor has decided to hide from the host.
It is not impossible. On a "HOST CALL" (explicit calls to the Host
from Realm), the GPRs are made available to the host and can be
stashed into the vcpu reg state and the request can be
serviced. However, it is a bit odd, to make this exception - "the
GET_ONE_REG is valid now", while in almost all other cases it is
invalid (exception of MMIO).
But that's an RMM decision. If the RMM decides to forward the
hypercall to the host (irrespective of the potential forwarding to
userspace), it makes the GPRs available.

If the hypercall is forwarded to userspace, then the host is
responsible to check with the RMM that it will be willing to provide
the required information (passed as GPRs or not).
Of course we could always return what is stashed in the vcpu state,
which is may be invalid/ 0. But given the construct of "host doesn't
have access to the register state", it may be a good idea to say,
request always fails, to indicate that the Host is probably doing
something wrong, than silently passing on incorrect information.
I disagree. Either you fail at the delegation point, or you don't. On
getting a hypercall exit to userspace, you are guaranteed that the
GPRs are valid.
quoted
Of course, it requires that the hypervisor (the RMM in your case)
knows about the semantics of the hypercall, but that's obviously
RMM doesn't care about the semantics of hypercall, other than
considering it just like an SMCCC compliant call. The hypercall
arguments/results are passed down/up by the Realm in a separate
structure.
That's because the RMM doesn't use registers to pass the data. But at
the end of the day, this is the same thing. The host gets the data
from the RMM, stashes it in the GPRs, and exit to userspace.

The important thing here is that GET_ONE_REG is valid in the context
where it matters. If the VMM tries to use it outside of the context of
a hypercall, it gets junk. It's not a bug, it's a feature.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help