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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/03/16 10:14, Juergen Gross wrote:
> On 23/03/16 10:29, Jan Beulich wrote:
>>>>> On 23.03.16 at 10:19, <JGross@xxxxxxxx> wrote:
>>> On 23/03/16 10:10, Jan Beulich wrote:
>>>>>>> On 23.03.16 at 08:50, <JGross@xxxxxxxx> 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.

I have to admit I don't understand the point of xen-detect in the first
place.  The differences between PV and HVM should be invisible to guest
userspace (the fact that userspace can tell to a certain extent reflects
how leaky the x86 architecture actually is).  Asking the kernel is the
only rational course of action.

If you want more help distinguishing PV for HVM, you can use larl/lsll
on the API-provided selectors, or sidt/sldt and finding the pointer
either pointing into userspace (when truncated for 32bit) or pointing
into the Xen-reserved memory region.

~Andrew

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