On 07.07.2023 12:16, Jan Beulich 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. > >> SYSCTLs are >> unfortunately not stable interfaces, correct? So it wouldn't be practical >> for systemd to use them. > > Indeed, neither sysctl-s nor the libxc interfaces are stable.
Thinking of it, xen-cpuid is a wrapper tool around those. They may want to look at its output (and, if they want to use it, advise distros to also package it), which I think we try to keep reasonably stable, albeit without providing any guarantees. Jan
