On Wed, Sep 04, 2024 at 09:01:03AM -0300, Jason Gunthorpe wrote: > 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. Yes, that’s for guests. What I meant is that the host sysregs are not read from userspace which is the synonym of reading SMMUv3 IDRs from userspace, instead the kernel controls what features are visible to userspace(VMM) which it can enable for guests if it wants, as SVE, MTE... Thanks, Mostafa > > Jason
