[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Detecting whether dom0 is in a VM
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 <jbeulich@xxxxxxxx> 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.
We haven't had any clear guidance yet on what the systemd team want in the <xen in a VM, systemd in a dom0> question; I just sort of assumed they wanted the L-1 virtualization *if possible*. It sounds like `vm-other` would be acceptable, particularly as a fall-back output if there's no way to get Xen's picture of the cpuid.
It looks like xen-cpuid is available on Fedora, Debian, Ubuntu, and the old Virt SIG CentOS packages; so I'd expect most packages to follow suit. That's a place to start.
Just to take the discussion all the way to its conclusion:
- Supposing xen-cpuid isn't available, is there any other way to tell if Xen is running in a VM from dom0?
- Would it make sense to expose that information somewhere, either in sysfs or in hypfs (or both?), so that eventually even systems which may not get the memo about packaging xen-cpuid will get support (or if the systemd guys would rather avoid executing another process if possible)?
-George
|
