On Tue, Sep 03, 2024 at 08:34:17AM +0000, Mostafa Saleh wrote: > > > For example, KVM doesn’t allow reading reading the CPU system > > > registers to know if SVE(or other features) is supported but hides > > > that by a CAP in KVM_CHECK_EXTENSION > > > > Do you know why? > > I am not really sure, but I believe it’s a useful abstraction It seems odd to me, unpriv userspace can look in /proc/cpuinfo and see SEV, why would kvm hide the same information behind a CAP_SYS_ADMIN/whatever check? > I don’t have a very strong opinion to sanitise the IDRs (specifically > many of those are documented anyway per IP), but at least we should have > some clear requirement for what userspace needs, I am just concerned > that userspace can misuse some of the features leading to a strange UAPI. We should probably have a file in Documentation/ that does more explaining of this. The design has the kernel be very general, the kernel's scope is bigger than just providing a vSMMU. It is the VMM's job to take the kernel tools and build the vSMMU para virtualization. It is like this because the configuration if the vSMMU is ultimately a policy choice that should be configured by the operator. When we consider live migration the vSMMU needs to be fully standardized and consistent regardless of what the pSMMU is. We don't want policy in the kernel. Jason
