On Wed, Sep 04, 2024 at 07:11:19AM +0000, Shameerali Kolothum Thodi wrote: > > 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 think KVM hides SVE always. It also depends on whether the > VMM has requested sve for a specific Guest or not(Qemu has option to > turn sve on/off, similarly pmu as well). Based on that KVM > populates the Guest specific ID registers. And Guest /proc/cpuinfo > reflects that. > > And for some features if KVM is not handling the feature properly or > not making any sense to be exposed to Guest, those features are > masked in ID registers. > > Recently ARM64 ID registers has been made writable from userspace to > allow VMM to turn on/off features, so that VMs can be migrated > between hosts that differ in feature support. > > https://lore.kernel.org/all/ZR2YfAixZgbCFnb8@xxxxxxxxx/T/#m7c2493fd2d43c13a3336d19f2dc06a89803c6fdb I see, so there is a significant difference - in KVM the kernel controls what ID values the VM observes and in vSMMU the VMM controls it. Jason
