On Fri, Jul 7, 2023 at 11:17 AM Jan Beulich <jbeul...@suse.com> wrote:
> On 07.07.2023 11:52, George Dunlap wrote: > > On Fri, Jul 7, 2023 at 9:00 AM Jan Beulich <jbeul...@suse.com> wrote: > > > >> On 06.07.2023 17:35, zithro wrote: > >>> On 06 Jul 2023 09:02, Jan Beulich wrote: > >>>> On 05.07.2023 18:20, zithro wrote: > >>>>> So I'm wondering, isn't that path enough for correct detection ? > >>>>> I mean, if "/sys/class/dmi/id/sys_vendor" reports Xen (or KVM, or any > >>>>> other known hypervisor), it's nested, otherwise it's on hardware ? > >>>>> > >>>>> Is that really mandatory to use CPUID leaves ? > >>>> > >>>> Let me ask the other way around: In user mode code under a non-nested > >>>> vs nested Xen, what would you be able to derive from CPUID? The > >>>> "hypervisor" bit is going to be set in both cases. (All assuming you > >>>> run on new enough hardware+Xen such that CPUID would be intercepted > >>>> even for PV.) > >>> > >>> I'm a bit clueless about CPUID stuff, but if I understand correctly, > >>> you're essentially saying that using CPUID may not be the perfect way ? > >>> Also, I don't get why the cpuid command returns two different values, > >>> depending on the -k switch : > >>> # cpuid -l 0x40000000 > >>> hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0" > >>> # cpuid -k -l 0x40000000 > >>> hypervisor_id (0x40000000) = "XenVMMXenVMM" > >> > >> I'm afraid I can't comment on this without knowing what tool you're > >> taking about. Neither of the two systems I checked have one of this > >> name. > >> > >>>> Yet relying on DMI is fragile, too: Along the lines of > >>>> https://lists.xen.org/archives/html/xen-devel/2022-01/msg00604.html > >>>> basically any value in there could be "inherited" from the host (i.e. > >>>> from the layer below, to be precise). > >>> > >>> So using "/sys/class/dmi/id/sys_vendor", or simply doing "dmesg | grep > >>> DMI:" is also not perfect, as values can be inherited/spoofed by > >>> underneath hypervisor ? > >> > >> That's my understanding, yes. > >> > >>>> The only way to be reasonably > >>>> certain is to ask Xen about its view. The raw or host featuresets > >>>> should give you this information, in the "mirror" of said respective > >>>> CPUID leave's "hypervisor" bit. > >>> > >>> As said above, I'm clueless, can you expand please ? > >> > >> Xen's public interface offers access to the featuresets known / found / > >> used by the hypervisor. See XEN_SYSCTL_get_cpu_featureset, accessible > >> via xc_get_cpu_featureset(). > >> > > > > Are any of these exposed in dom0 via sysctl, or hypfs? > > sysctl - yes (as the quoted name also says). hypfs no, afaict. > Sorry, that was a typo; I meant Linux's sysfs. But of course if it's a sysctl, I expect that to be a "no". -George
