Re: [PATCH] tools: fix xen-detect to correctly identify domU type

[Juergen Gross <jgross@suse.com>]

On 23/03/16 10:29, Jan Beulich wrote:
>>>> On 23.03.16 at 10:19, <JGross@suse.com> wrote:
>> On 23/03/16 10:10, Jan Beulich wrote:
>>>>>> On 23.03.16 at 08:50, <JGross@suse.com> wrote:
>>>> xen-detect always thinks a domU is running as HVM guest as the cpuid
>>>> instruction used to identify a Xen guest will always work.
>>>>
>>>> In order to identify a pv guest first try the pv special case of
>>>> cpuid (prefixed with an ud2a instruction and "xen" in ASCII). This
>>>> will fail on HVM and thus can be used to distinguish the guest types.
>>>
>>> I don't think that's something to be relied upon, or even true
>>> universally (see hvm_ud_intercept()). With CPUID faulting in mind
>>> I can't see a purely CPUID based mechanism that would reliably
>>> allow to tell one from the other as well as from PVH/PVHv2. There
>>> is one feature flag specifically getting set for PV domains only
>>> (XEN_CPUID_FEAT1_MMU_PT_UPDATE_PRESERVE_AD), but that
>>> won't be available on older hypervisors afaict.
>>
>> So this would mean we have the following options:
>>
>> a) nuke xen-detect completely, as it is unreliable
>> b) do the modification I've suggested, being better than the current
>>    version
>> c) modify it to ask the OS (is there an interface available we can
>>    use?)
>>
>> Thoughts?
> 
> Nuking is bad I think. If the tool can't reliably detect the mode,
> then I guess it should simply indicate so to the user. And if we
> can't figure a reliable method (I don't have the time right now to
> try to find possible ways), perhaps it should try more than one
> approach?

This would mean:
1. Try whether cpuid is allowed at all. If not, skip following cpuid
   based tests.
2. Look for Xen signature using prefixed and non-prefixed cpuid. If
   only one variant succeeds, type is clear and can be reported.
3. If none of the variants work, report "no Xen".
4. We don't know type. On Linux we can check for entries in
   /sys/hypervisor. If not present, report "don't know".
5. If /sys/hypervisor/type is not "xen", report "no Xen".
6. Check /sys/hypervisor/properties/features. If not present, report
   "don't know".
7. Report type according to features found (this is a little bit
   ugly: we have to rely on the current hypervisor implementation
   regarding the bits set for the different guest types).

Would it make sense to add another file to /sys/hypervisor/properties?
Something like guest_type, containing "pv", "hvm" or "pvh"? If existing
this could be used to report the guest type.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel