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?  SYSCTLs are
unfortunately not stable interfaces, correct?  So it wouldn't be practical
for systemd to use them.

 -George

Reply via email to