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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

Jan


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