Messages in this thread | | | Date | Tue, 7 Feb 2023 17:50:59 +0000 | Subject | Re: [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace | From | James Morse <> |
| |
Hi Oliver,
On 03/02/2023 21:08, Oliver Upton wrote: > On Fri, Feb 03, 2023 at 01:50:40PM +0000, James Morse wrote: >> From: Jean-Philippe Brucker <jean-philippe@linaro.org> >> >> When capability KVM_CAP_ARM_HVC_TO_USER is available, userspace can >> request to handle all hypercalls that aren't handled by KVM.
> I would very much prefer we not go down this route. This capability > effectively constructs an ABI out of what KVM presently does not > implement. What would happen if KVM decides to implement a new set > of hypercalls later down the road that were previously forwarded to > userspace?
The user-space support would never get called. If we have a wild-west allocation of IDs in this area we have bigger problems. I'd hope in this example it would be a VMM or an in-kernel implementation of the same feature.
When I floated something like this before for supporting SDEI in guests, Christoffer didn't like tie-ing KVM to SMC-CC - hence the all or nothing.
Since then we've had things like Spectre, which I don't think the VMM should ever be allowed to handle, which makes the whole thing much murkier.
> Instead of a catch-all I think we should take the approach of having > userspace explicitly request which hypercalls should be forwarded to > userspace. I proposed something similar [1], but never got around to > respinning it (oops).
> Let me dust those patches off and align with Marc's suggestions. > > [1]: https://lore.kernel.org/kvmarm/20221110015327.3389351-1-oliver.upton@linux.dev/
I've no problem with doing it like this. This approach was based on Christoffer's previous feedback, but the world has changed since then.
Let me know if you want me to re-spin that series - I need to get this into some shape next week for Salil to look at the Qemu changes, as I can't test the whole thing until that is done.
Thanks,
James
| |