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

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

[Juergen Gross]

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.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/misc/xen-detect.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/misc/xen-detect.c b/tools/misc/xen-detect.c
index 787b5da..342856c 100644
--- a/tools/misc/xen-detect.c
+++ b/tools/misc/xen-detect.c
@@ -133,15 +133,10 @@ int main(int argc, char **argv)
         }
     }
 
-    /* Check for execution in HVM context. */
-    detected = XEN_HVM;
-    if ( (version = check_for_xen(0)) != 0 )
-        goto out;
-
     /*
      * Set up a signal handler to test the paravirtualised CPUID instruction.
      * If executed outside Xen PV context, the extended opcode will fault, we
-     * will longjmp via the signal handler, and print "Not running on Xen".
+     * will longjmp via the signal handler, and test for HVM.
      */
     detected = XEN_PV;
     if ( !setjmp(sigill_jmp)
@@ -149,6 +144,11 @@ int main(int argc, char **argv)
          && ((version = check_for_xen(1)) != 0) )
         goto out;
 
+    /* Check for execution in HVM context. */
+    detected = XEN_HVM;
+    if ( !setjmp(sigill_jmp) && (version = check_for_xen(0)) != 0 )
+        goto out;
+
     detected = XEN_NONE;
 
  out:
-- 
2.6.2


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

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

[Jan Beulich]

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

Jan


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

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

[Juergen Gross]

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?


Juergen


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

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

[Jan Beulich]

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

Jan


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

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

[Juergen Gross]

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

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

[Jan Beulich]

>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
> 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).

Well, in some of the cases feature flags only make sense for one
kind of guest, so if such a flag is set it could be used as positive
indication (while it being clear may then still mean nothing).

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

That would seem a good idea to me. What do others, namely
Linux maintainers, think?

Jan


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

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

[David Vrabel]

On 23/03/16 10:25, Jan Beulich wrote:
>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>> 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).
> 
> Well, in some of the cases feature flags only make sense for one
> kind of guest, so if such a flag is set it could be used as positive
> indication (while it being clear may then still mean nothing).
> 
>> 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.
> 
> That would seem a good idea to me. What do others, namely
> Linux maintainers, think?

What's the use case for user space knowing if it's in a PV or HVM domain?

David

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

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

[Juergen Gross]

On 23/03/16 11:32, David Vrabel wrote:
> On 23/03/16 10:25, Jan Beulich wrote:
>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>> 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).
>>
>> Well, in some of the cases feature flags only make sense for one
>> kind of guest, so if such a flag is set it could be used as positive
>> indication (while it being clear may then still mean nothing).
>>
>>> 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.
>>
>> That would seem a good idea to me. What do others, namely
>> Linux maintainers, think?
> 
> What's the use case for user space knowing if it's in a PV or HVM domain?

The first thing coming to my mind would be diagnostic tools.


juergen


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

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

[Andrew Cooper]

On 23/03/16 10:52, Juergen Gross wrote:
> On 23/03/16 11:32, David Vrabel wrote:
>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>> 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).
>>> Well, in some of the cases feature flags only make sense for one
>>> kind of guest, so if such a flag is set it could be used as positive
>>> indication (while it being clear may then still mean nothing).
>>>
>>>> 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.
>>> That would seem a good idea to me. What do others, namely
>>> Linux maintainers, think?
>> What's the use case for user space knowing if it's in a PV or HVM domain?
> The first thing coming to my mind would be diagnostic tools.

Having the admin able to tell for informational purposes is useful. 
They can find out by looking at the top of `dmesg`, but a hypervisor
sysfs node is cleaner than requiring the admin to know every printk()
variant that Xen puts out.

That is it however.  It specifically shouldn't be used for any other
decisions, as it isn't relevant.

~Andrew

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

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

[David Vrabel]

On 23/03/16 10:55, Andrew Cooper wrote:
> On 23/03/16 10:52, Juergen Gross wrote:
>> On 23/03/16 11:32, David Vrabel wrote:
>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>> 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).
>>>> Well, in some of the cases feature flags only make sense for one
>>>> kind of guest, so if such a flag is set it could be used as positive
>>>> indication (while it being clear may then still mean nothing).
>>>>
>>>>> 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.
>>>> That would seem a good idea to me. What do others, namely
>>>> Linux maintainers, think?
>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>> The first thing coming to my mind would be diagnostic tools.
> 
> Having the admin able to tell for informational purposes is useful. 
> They can find out by looking at the top of `dmesg`, but a hypervisor
> sysfs node is cleaner than requiring the admin to know every printk()
> variant that Xen puts out.
> 
> That is it however.  It specifically shouldn't be used for any other
> decisions, as it isn't relevant.

I think it should be the toolstack that presents this information.

I don't think we should add a new kernel ABI for this.

David


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

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

[Andrew Cooper]

On 23/03/16 10:59, David Vrabel wrote:
> On 23/03/16 10:55, Andrew Cooper wrote:
>> On 23/03/16 10:52, Juergen Gross wrote:
>>> On 23/03/16 11:32, David Vrabel wrote:
>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>> 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).
>>>>> Well, in some of the cases feature flags only make sense for one
>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>> indication (while it being clear may then still mean nothing).
>>>>>
>>>>>> 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.
>>>>> That would seem a good idea to me. What do others, namely
>>>>> Linux maintainers, think?
>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>> The first thing coming to my mind would be diagnostic tools.
>> Having the admin able to tell for informational purposes is useful. 
>> They can find out by looking at the top of `dmesg`, but a hypervisor
>> sysfs node is cleaner than requiring the admin to know every printk()
>> variant that Xen puts out.
>>
>> That is it however.  It specifically shouldn't be used for any other
>> decisions, as it isn't relevant.
> I think it should be the toolstack that presents this information.
>
> I don't think we should add a new kernel ABI for this.

A toolstack is not present in a domU.

~Andrew

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

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

[David Vrabel]

On 23/03/16 11:12, Andrew Cooper wrote:
> On 23/03/16 10:59, David Vrabel wrote:
>> On 23/03/16 10:55, Andrew Cooper wrote:
>>> On 23/03/16 10:52, Juergen Gross wrote:
>>>> On 23/03/16 11:32, David Vrabel wrote:
>>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>>> 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).
>>>>>> Well, in some of the cases feature flags only make sense for one
>>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>>> indication (while it being clear may then still mean nothing).
>>>>>>
>>>>>>> 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.
>>>>>> That would seem a good idea to me. What do others, namely
>>>>>> Linux maintainers, think?
>>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>>> The first thing coming to my mind would be diagnostic tools.
>>> Having the admin able to tell for informational purposes is useful. 

This is useful because...?

>>> They can find out by looking at the top of `dmesg`, but a hypervisor
>>> sysfs node is cleaner than requiring the admin to know every printk()
>>> variant that Xen puts out.
>>>
>>> That is it however.  It specifically shouldn't be used for any other
>>> decisions, as it isn't relevant.
>> I think it should be the toolstack that presents this information.
>>
>> I don't think we should add a new kernel ABI for this.
> 
> A toolstack is not present in a domU.

So?  The guest admin doesn't need to be in the guest itself to get this
information -- it's right there is the xl configuration for the guest.

David

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

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

[Andrew Cooper]

On 23/03/16 11:18, David Vrabel wrote:
> On 23/03/16 11:12, Andrew Cooper wrote:
>> On 23/03/16 10:59, David Vrabel wrote:
>>> On 23/03/16 10:55, Andrew Cooper wrote:
>>>> On 23/03/16 10:52, Juergen Gross wrote:
>>>>> On 23/03/16 11:32, David Vrabel wrote:
>>>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>>>> 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).
>>>>>>> Well, in some of the cases feature flags only make sense for one
>>>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>>>> indication (while it being clear may then still mean nothing).
>>>>>>>
>>>>>>>> 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.
>>>>>>> That would seem a good idea to me. What do others, namely
>>>>>>> Linux maintainers, think?
>>>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>>>> The first thing coming to my mind would be diagnostic tools.
>>>> Having the admin able to tell for informational purposes is useful. 
> This is useful because...?

Independently verifying that the guest is as expected?

>
>>>> They can find out by looking at the top of `dmesg`, but a hypervisor
>>>> sysfs node is cleaner than requiring the admin to know every printk()
>>>> variant that Xen puts out.
>>>>
>>>> That is it however.  It specifically shouldn't be used for any other
>>>> decisions, as it isn't relevant.
>>> I think it should be the toolstack that presents this information.
>>>
>>> I don't think we should add a new kernel ABI for this.
>> A toolstack is not present in a domU.
> So?  The guest admin doesn't need to be in the guest itself to get this
> information -- it's right there is the xl configuration for the guest.

guest admin != host admin, and had better not have access to dom0.

~Andrew

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

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

[Juergen Gross]

On 23/03/16 12:25, Andrew Cooper wrote:
> On 23/03/16 11:18, David Vrabel wrote:
>> On 23/03/16 11:12, Andrew Cooper wrote:
>>> On 23/03/16 10:59, David Vrabel wrote:
>>>> On 23/03/16 10:55, Andrew Cooper wrote:
>>>>> On 23/03/16 10:52, Juergen Gross wrote:
>>>>>> On 23/03/16 11:32, David Vrabel wrote:
>>>>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>>>>> 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).
>>>>>>>> Well, in some of the cases feature flags only make sense for one
>>>>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>>>>> indication (while it being clear may then still mean nothing).
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> That would seem a good idea to me. What do others, namely
>>>>>>>> Linux maintainers, think?
>>>>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>>>>> The first thing coming to my mind would be diagnostic tools.
>>>>> Having the admin able to tell for informational purposes is useful. 
>> This is useful because...?
> 
> Independently verifying that the guest is as expected?
> 
>>
>>>>> They can find out by looking at the top of `dmesg`, but a hypervisor
>>>>> sysfs node is cleaner than requiring the admin to know every printk()
>>>>> variant that Xen puts out.
>>>>>
>>>>> That is it however.  It specifically shouldn't be used for any other
>>>>> decisions, as it isn't relevant.
>>>> I think it should be the toolstack that presents this information.
>>>>
>>>> I don't think we should add a new kernel ABI for this.
>>> A toolstack is not present in a domU.
>> So?  The guest admin doesn't need to be in the guest itself to get this
>> information -- it's right there is the xl configuration for the guest.
> 
> guest admin != host admin, and had better not have access to dom0.

David, do you agree on adding another /sys file? Or do you still think
this is no good idea? In case you don't like it, do you have a better
alternative?


Juergen


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

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

[David Vrabel]

On 23/03/16 19:03, Juergen Gross wrote:
> On 23/03/16 12:25, Andrew Cooper wrote:
>> On 23/03/16 11:18, David Vrabel wrote:
>>> On 23/03/16 11:12, Andrew Cooper wrote:
>>>> On 23/03/16 10:59, David Vrabel wrote:
>>>>> On 23/03/16 10:55, Andrew Cooper wrote:
>>>>>> On 23/03/16 10:52, Juergen Gross wrote:
>>>>>>> On 23/03/16 11:32, David Vrabel wrote:
>>>>>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>>>>>> 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).
>>>>>>>>> Well, in some of the cases feature flags only make sense for one
>>>>>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>>>>>> indication (while it being clear may then still mean nothing).
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>> That would seem a good idea to me. What do others, namely
>>>>>>>>> Linux maintainers, think?
>>>>>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>>>>>> The first thing coming to my mind would be diagnostic tools.
>>>>>> Having the admin able to tell for informational purposes is useful. 
>>> This is useful because...?
>>
>> Independently verifying that the guest is as expected?
>>
>>>
>>>>>> They can find out by looking at the top of `dmesg`, but a hypervisor
>>>>>> sysfs node is cleaner than requiring the admin to know every printk()
>>>>>> variant that Xen puts out.
>>>>>>
>>>>>> That is it however.  It specifically shouldn't be used for any other
>>>>>> decisions, as it isn't relevant.
>>>>> I think it should be the toolstack that presents this information.
>>>>>
>>>>> I don't think we should add a new kernel ABI for this.
>>>> A toolstack is not present in a domU.
>>> So?  The guest admin doesn't need to be in the guest itself to get this
>>> information -- it's right there is the xl configuration for the guest.
>>
>> guest admin != host admin, and had better not have access to dom0.
> 
> David, do you agree on adding another /sys file? Or do you still think
> this is no good idea? In case you don't like it, do you have a better
> alternative?

I am not convinced that the use case is sufficiently compelling to
warrant adding to the Linux kernel ABI.

New ABIs need to solve problems not just present possibly useful
information.

David

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

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

[Juergen Gross]

On 24/03/16 11:22, David Vrabel wrote:
> On 23/03/16 19:03, Juergen Gross wrote:
>> On 23/03/16 12:25, Andrew Cooper wrote:
>>> On 23/03/16 11:18, David Vrabel wrote:
>>>> On 23/03/16 11:12, Andrew Cooper wrote:
>>>>> On 23/03/16 10:59, David Vrabel wrote:
>>>>>> On 23/03/16 10:55, Andrew Cooper wrote:
>>>>>>> On 23/03/16 10:52, Juergen Gross wrote:
>>>>>>>> On 23/03/16 11:32, David Vrabel wrote:
>>>>>>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>>>>>>> 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).
>>>>>>>>>> Well, in some of the cases feature flags only make sense for one
>>>>>>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>>>>>>> indication (while it being clear may then still mean nothing).
>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>> That would seem a good idea to me. What do others, namely
>>>>>>>>>> Linux maintainers, think?
>>>>>>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>>>>>>> The first thing coming to my mind would be diagnostic tools.
>>>>>>> Having the admin able to tell for informational purposes is useful. 
>>>> This is useful because...?
>>>
>>> Independently verifying that the guest is as expected?
>>>
>>>>
>>>>>>> They can find out by looking at the top of `dmesg`, but a hypervisor
>>>>>>> sysfs node is cleaner than requiring the admin to know every printk()
>>>>>>> variant that Xen puts out.
>>>>>>>
>>>>>>> That is it however.  It specifically shouldn't be used for any other
>>>>>>> decisions, as it isn't relevant.
>>>>>> I think it should be the toolstack that presents this information.
>>>>>>
>>>>>> I don't think we should add a new kernel ABI for this.
>>>>> A toolstack is not present in a domU.
>>>> So?  The guest admin doesn't need to be in the guest itself to get this
>>>> information -- it's right there is the xl configuration for the guest.
>>>
>>> guest admin != host admin, and had better not have access to dom0.
>>
>> David, do you agree on adding another /sys file? Or do you still think
>> this is no good idea? In case you don't like it, do you have a better
>> alternative?
> 
> I am not convinced that the use case is sufficiently compelling to
> warrant adding to the Linux kernel ABI.
> 
> New ABIs need to solve problems not just present possibly useful
> information.

I've searched a little bit in git history in order to understand why
xen-detect has been invented and/or has all the options which clearly
are meant to be used in scripts.

The last large modification was done in 2009 and I think Konrad is to
blame here. ;-)

It was meant to be used in early boot sequence to autoload the needed
modules (frontends/backends) in case of running on top of Xen. I believe
this usage isn't needed any longer as the dom0 case is handled
differently and the needed frontends are loaded automatically on demand.

So this means we can drop all the options of xen-detect, as they serve
no purpose today.

Next question is whether the remaining functionality warrants keeping
xen-detect, and how the information it is presenting can be obtained.

If we want to keep it, I can think of following solutions:
- new kernel ABI (as suggested, David doesn't like it)
- follow the route it is taking today, information is unreliable
- parsing of the boot messages (e.g. via an init script into a file)
  and printing that information (would work, but is a little bit hacky)

Thoughts?


Juergen

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

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

[Andrew Cooper]

On 24/03/16 10:58, Juergen Gross wrote:
> I've searched a little bit in git history in order to understand why
> xen-detect has been invented and/or has all the options which clearly
> are meant to be used in scripts.
>
> The last large modification was done in 2009 and I think Konrad is to
> blame here. ;-)
>
> It was meant to be used in early boot sequence to autoload the needed
> modules (frontends/backends) in case of running on top of Xen. I believe
> this usage isn't needed any longer as the dom0 case is handled
> differently and the needed frontends are loaded automatically on demand.
>
> So this means we can drop all the options of xen-detect, as they serve
> no purpose today.
>
> Next question is whether the remaining functionality warrants keeping
> xen-detect, and how the information it is presenting can be obtained.
>
> If we want to keep it, I can think of following solutions:
> - new kernel ABI (as suggested, David doesn't like it)
> - follow the route it is taking today, information is unreliable
> - parsing of the boot messages (e.g. via an init script into a file)
>   and printing that information (would work, but is a little bit hacky)
>
> Thoughts?

I don't recommend keeping xen-detect.  It is unreliable, and we will
always be playing catchup.

Parsing? that's not a little hacky...  The ABI is definitely a better
solution.

As for the ABI,

[root@fusebot ~]# find /sys/hypervisor/
/sys/hypervisor/
/sys/hypervisor/type
/sys/hypervisor/uuid
/sys/hypervisor/compilation
/sys/hypervisor/compilation/compiled_by
/sys/hypervisor/compilation/compile_date
/sys/hypervisor/compilation/compiler
/sys/hypervisor/properties
/sys/hypervisor/properties/pagesize
/sys/hypervisor/properties/changeset
/sys/hypervisor/properties/virtual_start
/sys/hypervisor/properties/features
/sys/hypervisor/properties/capabilities
/sys/hypervisor/version
/sys/hypervisor/version/extra
/sys/hypervisor/version/major
/sys/hypervisor/version/minor

A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
and is applicable to all hypervisors, not just Xen.

~Andrew

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

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

[George Dunlap]

On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 24/03/16 10:58, Juergen Gross wrote:
>> I've searched a little bit in git history in order to understand why
>> xen-detect has been invented and/or has all the options which clearly
>> are meant to be used in scripts.
>>
>> The last large modification was done in 2009 and I think Konrad is to
>> blame here. ;-)
>>
>> It was meant to be used in early boot sequence to autoload the needed
>> modules (frontends/backends) in case of running on top of Xen. I believe
>> this usage isn't needed any longer as the dom0 case is handled
>> differently and the needed frontends are loaded automatically on demand.
>>
>> So this means we can drop all the options of xen-detect, as they serve
>> no purpose today.
>>
>> Next question is whether the remaining functionality warrants keeping
>> xen-detect, and how the information it is presenting can be obtained.
>>
>> If we want to keep it, I can think of following solutions:
>> - new kernel ABI (as suggested, David doesn't like it)
>> - follow the route it is taking today, information is unreliable
>> - parsing of the boot messages (e.g. via an init script into a file)
>>   and printing that information (would work, but is a little bit hacky)
>>
>> Thoughts?
>
> I don't recommend keeping xen-detect.  It is unreliable, and we will
> always be playing catchup.
>
> Parsing? that's not a little hacky...  The ABI is definitely a better
> solution.
>
> As for the ABI,
>
> [root@fusebot ~]# find /sys/hypervisor/
> /sys/hypervisor/
> /sys/hypervisor/type
> /sys/hypervisor/uuid
> /sys/hypervisor/compilation
> /sys/hypervisor/compilation/compiled_by
> /sys/hypervisor/compilation/compile_date
> /sys/hypervisor/compilation/compiler
> /sys/hypervisor/properties
> /sys/hypervisor/properties/pagesize
> /sys/hypervisor/properties/changeset
> /sys/hypervisor/properties/virtual_start
> /sys/hypervisor/properties/features
> /sys/hypervisor/properties/capabilities
> /sys/hypervisor/version
> /sys/hypervisor/version/extra
> /sys/hypervisor/version/major
> /sys/hypervisor/version/minor
>
> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
> and is applicable to all hypervisors, not just Xen.

FWIW this sounds reasonable to me.

 -George

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

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

[Juergen Gross]

On 24/03/16 12:38, George Dunlap wrote:
> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
>> On 24/03/16 10:58, Juergen Gross wrote:
>>> I've searched a little bit in git history in order to understand why
>>> xen-detect has been invented and/or has all the options which clearly
>>> are meant to be used in scripts.
>>>
>>> The last large modification was done in 2009 and I think Konrad is to
>>> blame here. ;-)
>>>
>>> It was meant to be used in early boot sequence to autoload the needed
>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>> this usage isn't needed any longer as the dom0 case is handled
>>> differently and the needed frontends are loaded automatically on demand.
>>>
>>> So this means we can drop all the options of xen-detect, as they serve
>>> no purpose today.
>>>
>>> Next question is whether the remaining functionality warrants keeping
>>> xen-detect, and how the information it is presenting can be obtained.
>>>
>>> If we want to keep it, I can think of following solutions:
>>> - new kernel ABI (as suggested, David doesn't like it)
>>> - follow the route it is taking today, information is unreliable
>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>   and printing that information (would work, but is a little bit hacky)
>>>
>>> Thoughts?
>>
>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>> always be playing catchup.
>>
>> Parsing? that's not a little hacky...  The ABI is definitely a better
>> solution.
>>
>> As for the ABI,
>>
>> [root@fusebot ~]# find /sys/hypervisor/
>> /sys/hypervisor/
>> /sys/hypervisor/type
>> /sys/hypervisor/uuid
>> /sys/hypervisor/compilation
>> /sys/hypervisor/compilation/compiled_by
>> /sys/hypervisor/compilation/compile_date
>> /sys/hypervisor/compilation/compiler
>> /sys/hypervisor/properties
>> /sys/hypervisor/properties/pagesize
>> /sys/hypervisor/properties/changeset
>> /sys/hypervisor/properties/virtual_start
>> /sys/hypervisor/properties/features
>> /sys/hypervisor/properties/capabilities
>> /sys/hypervisor/version
>> /sys/hypervisor/version/extra
>> /sys/hypervisor/version/major
>> /sys/hypervisor/version/minor
>>
>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>> and is applicable to all hypervisors, not just Xen.
> 
> FWIW this sounds reasonable to me.

Another sum up:

- common sense seems to be the current way xen-detect is trying to
  guess the guest type is unreliable and should be dropped (Jan
  would like to keep it, but I guess he just wants the information
  to be available - is this correct, Jan?)
- the command line options of xen-detect are not necessary any more
- the information which guest type we are should be obtainable from
  inside the guest, the consumer of this information should be humans
  only
- the OS already knows in which mode it is running, so it should be the
  kernel to present that information (David disagrees here: he isn't
  convinced this information is it worth to add another kernel
  interface)

As there is no real hurry to have this topic settled I'd suggest we just
discuss it at the Hackathon (all involved in the discussion so far but
George will be there). What do you think?


Juergen


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

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

[Jan Beulich]

>>> On 25.03.16 at 09:54, <JGross@suse.com> wrote:
> Another sum up:
> 
> - common sense seems to be the current way xen-detect is trying to
>   guess the guest type is unreliable and should be dropped (Jan
>   would like to keep it, but I guess he just wants the information
>   to be available - is this correct, Jan?)

I just didn't want something that might be useful (even if only
for debugging purposes) to get dropped without some further
thinking about it. It's a tools/ component, so I'll trust the
judgment of the tools maintainers in this regard.

Jan

> - the command line options of xen-detect are not necessary any more
> - the information which guest type we are should be obtainable from
>   inside the guest, the consumer of this information should be humans
>   only
> - the OS already knows in which mode it is running, so it should be the
>   kernel to present that information (David disagrees here: he isn't
>   convinced this information is it worth to add another kernel
>   interface)
> 
> As there is no real hurry to have this topic settled I'd suggest we just
> discuss it at the Hackathon (all involved in the discussion so far but
> George will be there). What do you think?
> 
> 
> Juergen




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

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

[George Dunlap]

On 25/03/16 08:54, Juergen Gross wrote:
> On 24/03/16 12:38, George Dunlap wrote:
>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>> <andrew.cooper3@citrix.com> wrote:
>>> On 24/03/16 10:58, Juergen Gross wrote:
>>>> I've searched a little bit in git history in order to understand why
>>>> xen-detect has been invented and/or has all the options which clearly
>>>> are meant to be used in scripts.
>>>>
>>>> The last large modification was done in 2009 and I think Konrad is to
>>>> blame here. ;-)
>>>>
>>>> It was meant to be used in early boot sequence to autoload the needed
>>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>>> this usage isn't needed any longer as the dom0 case is handled
>>>> differently and the needed frontends are loaded automatically on demand.
>>>>
>>>> So this means we can drop all the options of xen-detect, as they serve
>>>> no purpose today.
>>>>
>>>> Next question is whether the remaining functionality warrants keeping
>>>> xen-detect, and how the information it is presenting can be obtained.
>>>>
>>>> If we want to keep it, I can think of following solutions:
>>>> - new kernel ABI (as suggested, David doesn't like it)
>>>> - follow the route it is taking today, information is unreliable
>>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>>   and printing that information (would work, but is a little bit hacky)
>>>>
>>>> Thoughts?
>>>
>>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>>> always be playing catchup.
>>>
>>> Parsing? that's not a little hacky...  The ABI is definitely a better
>>> solution.
>>>
>>> As for the ABI,
>>>
>>> [root@fusebot ~]# find /sys/hypervisor/
>>> /sys/hypervisor/
>>> /sys/hypervisor/type
>>> /sys/hypervisor/uuid
>>> /sys/hypervisor/compilation
>>> /sys/hypervisor/compilation/compiled_by
>>> /sys/hypervisor/compilation/compile_date
>>> /sys/hypervisor/compilation/compiler
>>> /sys/hypervisor/properties
>>> /sys/hypervisor/properties/pagesize
>>> /sys/hypervisor/properties/changeset
>>> /sys/hypervisor/properties/virtual_start
>>> /sys/hypervisor/properties/features
>>> /sys/hypervisor/properties/capabilities
>>> /sys/hypervisor/version
>>> /sys/hypervisor/version/extra
>>> /sys/hypervisor/version/major
>>> /sys/hypervisor/version/minor
>>>
>>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>>> and is applicable to all hypervisors, not just Xen.
>>
>> FWIW this sounds reasonable to me.
> 
> Another sum up:
> 
> - common sense seems to be the current way xen-detect is trying to
>   guess the guest type is unreliable and should be dropped (Jan
>   would like to keep it, but I guess he just wants the information
>   to be available - is this correct, Jan?)
> - the command line options of xen-detect are not necessary any more
> - the information which guest type we are should be obtainable from
>   inside the guest, the consumer of this information should be humans
>   only
> - the OS already knows in which mode it is running, so it should be the
>   kernel to present that information (David disagrees here: he isn't
>   convinced this information is it worth to add another kernel
>   interface)
> 
> As there is no real hurry to have this topic settled I'd suggest we just
> discuss it at the Hackathon (all involved in the discussion so far but
> George will be there). What do you think?

I just signed up, so I'll be there too. :-)

So if we decide not to add a /sys/hypervisor/guest_type node, I guess
we'll probably be deleting this anyway.  The next question is, if we
*do* add such a node, will we replace xen-detect with a program that
simply reports the value of this node?  Or are we planning on deleting
it either way?

If we're planning on deleting it either way, I'd be in favor of deleting
it now, so that it can be gone from 4.7.

 -George

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

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

[Juergen Gross]

On 29/03/16 15:54, George Dunlap wrote:
> On 25/03/16 08:54, Juergen Gross wrote:
>> On 24/03/16 12:38, George Dunlap wrote:
>>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>>> <andrew.cooper3@citrix.com> wrote:
>>>> On 24/03/16 10:58, Juergen Gross wrote:
>>>>> I've searched a little bit in git history in order to understand why
>>>>> xen-detect has been invented and/or has all the options which clearly
>>>>> are meant to be used in scripts.
>>>>>
>>>>> The last large modification was done in 2009 and I think Konrad is to
>>>>> blame here. ;-)
>>>>>
>>>>> It was meant to be used in early boot sequence to autoload the needed
>>>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>>>> this usage isn't needed any longer as the dom0 case is handled
>>>>> differently and the needed frontends are loaded automatically on demand.
>>>>>
>>>>> So this means we can drop all the options of xen-detect, as they serve
>>>>> no purpose today.
>>>>>
>>>>> Next question is whether the remaining functionality warrants keeping
>>>>> xen-detect, and how the information it is presenting can be obtained.
>>>>>
>>>>> If we want to keep it, I can think of following solutions:
>>>>> - new kernel ABI (as suggested, David doesn't like it)
>>>>> - follow the route it is taking today, information is unreliable
>>>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>>>   and printing that information (would work, but is a little bit hacky)
>>>>>
>>>>> Thoughts?
>>>>
>>>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>>>> always be playing catchup.
>>>>
>>>> Parsing? that's not a little hacky...  The ABI is definitely a better
>>>> solution.
>>>>
>>>> As for the ABI,
>>>>
>>>> [root@fusebot ~]# find /sys/hypervisor/
>>>> /sys/hypervisor/
>>>> /sys/hypervisor/type
>>>> /sys/hypervisor/uuid
>>>> /sys/hypervisor/compilation
>>>> /sys/hypervisor/compilation/compiled_by
>>>> /sys/hypervisor/compilation/compile_date
>>>> /sys/hypervisor/compilation/compiler
>>>> /sys/hypervisor/properties
>>>> /sys/hypervisor/properties/pagesize
>>>> /sys/hypervisor/properties/changeset
>>>> /sys/hypervisor/properties/virtual_start
>>>> /sys/hypervisor/properties/features
>>>> /sys/hypervisor/properties/capabilities
>>>> /sys/hypervisor/version
>>>> /sys/hypervisor/version/extra
>>>> /sys/hypervisor/version/major
>>>> /sys/hypervisor/version/minor
>>>>
>>>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>>>> and is applicable to all hypervisors, not just Xen.
>>>
>>> FWIW this sounds reasonable to me.
>>
>> Another sum up:
>>
>> - common sense seems to be the current way xen-detect is trying to
>>   guess the guest type is unreliable and should be dropped (Jan
>>   would like to keep it, but I guess he just wants the information
>>   to be available - is this correct, Jan?)
>> - the command line options of xen-detect are not necessary any more
>> - the information which guest type we are should be obtainable from
>>   inside the guest, the consumer of this information should be humans
>>   only
>> - the OS already knows in which mode it is running, so it should be the
>>   kernel to present that information (David disagrees here: he isn't
>>   convinced this information is it worth to add another kernel
>>   interface)
>>
>> As there is no real hurry to have this topic settled I'd suggest we just
>> discuss it at the Hackathon (all involved in the discussion so far but
>> George will be there). What do you think?
> 
> I just signed up, so I'll be there too. :-)
> 
> So if we decide not to add a /sys/hypervisor/guest_type node, I guess
> we'll probably be deleting this anyway.  The next question is, if we
> *do* add such a node, will we replace xen-detect with a program that
> simply reports the value of this node?  Or are we planning on deleting
> it either way?

+1 for deleting it. Installing a program which is just doing a "cat" of
a file is nonsense IMO.

> 
> If we're planning on deleting it either way, I'd be in favor of deleting
> it now, so that it can be gone from 4.7.

+1


Juergen


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

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

[George Dunlap]

On 29/03/16 15:00, Juergen Gross wrote:
> On 29/03/16 15:54, George Dunlap wrote:
>> On 25/03/16 08:54, Juergen Gross wrote:
>>> On 24/03/16 12:38, George Dunlap wrote:
>>>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>>>> <andrew.cooper3@citrix.com> wrote:
>>>>> On 24/03/16 10:58, Juergen Gross wrote:
>>>>>> I've searched a little bit in git history in order to understand why
>>>>>> xen-detect has been invented and/or has all the options which clearly
>>>>>> are meant to be used in scripts.
>>>>>>
>>>>>> The last large modification was done in 2009 and I think Konrad is to
>>>>>> blame here. ;-)
>>>>>>
>>>>>> It was meant to be used in early boot sequence to autoload the needed
>>>>>> modules (frontends/backends) in case of running on top of Xen. I believe
>>>>>> this usage isn't needed any longer as the dom0 case is handled
>>>>>> differently and the needed frontends are loaded automatically on demand.
>>>>>>
>>>>>> So this means we can drop all the options of xen-detect, as they serve
>>>>>> no purpose today.
>>>>>>
>>>>>> Next question is whether the remaining functionality warrants keeping
>>>>>> xen-detect, and how the information it is presenting can be obtained.
>>>>>>
>>>>>> If we want to keep it, I can think of following solutions:
>>>>>> - new kernel ABI (as suggested, David doesn't like it)
>>>>>> - follow the route it is taking today, information is unreliable
>>>>>> - parsing of the boot messages (e.g. via an init script into a file)
>>>>>>   and printing that information (would work, but is a little bit hacky)
>>>>>>
>>>>>> Thoughts?
>>>>>
>>>>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>>>>> always be playing catchup.
>>>>>
>>>>> Parsing? that's not a little hacky...  The ABI is definitely a better
>>>>> solution.
>>>>>
>>>>> As for the ABI,
>>>>>
>>>>> [root@fusebot ~]# find /sys/hypervisor/
>>>>> /sys/hypervisor/
>>>>> /sys/hypervisor/type
>>>>> /sys/hypervisor/uuid
>>>>> /sys/hypervisor/compilation
>>>>> /sys/hypervisor/compilation/compiled_by
>>>>> /sys/hypervisor/compilation/compile_date
>>>>> /sys/hypervisor/compilation/compiler
>>>>> /sys/hypervisor/properties
>>>>> /sys/hypervisor/properties/pagesize
>>>>> /sys/hypervisor/properties/changeset
>>>>> /sys/hypervisor/properties/virtual_start
>>>>> /sys/hypervisor/properties/features
>>>>> /sys/hypervisor/properties/capabilities
>>>>> /sys/hypervisor/version
>>>>> /sys/hypervisor/version/extra
>>>>> /sys/hypervisor/version/major
>>>>> /sys/hypervisor/version/minor
>>>>>
>>>>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>>>>> and is applicable to all hypervisors, not just Xen.
>>>>
>>>> FWIW this sounds reasonable to me.
>>>
>>> Another sum up:
>>>
>>> - common sense seems to be the current way xen-detect is trying to
>>>   guess the guest type is unreliable and should be dropped (Jan
>>>   would like to keep it, but I guess he just wants the information
>>>   to be available - is this correct, Jan?)
>>> - the command line options of xen-detect are not necessary any more
>>> - the information which guest type we are should be obtainable from
>>>   inside the guest, the consumer of this information should be humans
>>>   only
>>> - the OS already knows in which mode it is running, so it should be the
>>>   kernel to present that information (David disagrees here: he isn't
>>>   convinced this information is it worth to add another kernel
>>>   interface)
>>>
>>> As there is no real hurry to have this topic settled I'd suggest we just
>>> discuss it at the Hackathon (all involved in the discussion so far but
>>> George will be there). What do you think?
>>
>> I just signed up, so I'll be there too. :-)
>>
>> So if we decide not to add a /sys/hypervisor/guest_type node, I guess
>> we'll probably be deleting this anyway.  The next question is, if we
>> *do* add such a node, will we replace xen-detect with a program that
>> simply reports the value of this node?  Or are we planning on deleting
>> it either way?
> 
> +1 for deleting it. Installing a program which is just doing a "cat" of
> a file is nonsense IMO.

Well running "xen-detect" is certainly a lot better interface than "cat
/sys/hypervisor/guest_type".  An argument could also be made that
maintaining the existing interface is worthwhile -- all the scripts that
currently run xen-detect would continue to operate as they always had
been, rather than breaking and needing to be re-written.

Unfortunately it's a bit hard to know how valuable this would actually be.

 -George

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

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

[Juergen Gross]

On 23/03/16 11:55, Andrew Cooper wrote:
> On 23/03/16 10:52, Juergen Gross wrote:
>> On 23/03/16 11:32, David Vrabel wrote:
>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>> 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).
>>>> Well, in some of the cases feature flags only make sense for one
>>>> kind of guest, so if such a flag is set it could be used as positive
>>>> indication (while it being clear may then still mean nothing).
>>>>
>>>>> 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.
>>>> That would seem a good idea to me. What do others, namely
>>>> Linux maintainers, think?
>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>> The first thing coming to my mind would be diagnostic tools.
> 
> Having the admin able to tell for informational purposes is useful. 
> They can find out by looking at the top of `dmesg`, but a hypervisor
> sysfs node is cleaner than requiring the admin to know every printk()
> variant that Xen puts out.

Especially on a long running guest this information might be not
available in case of trouble.


Juergen


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

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

[Boris Ostrovsky]

On 03/23/2016 07:33 AM, Juergen Gross wrote:
> On 23/03/16 11:55, Andrew Cooper wrote:
>> On 23/03/16 10:52, Juergen Gross wrote:
>>> On 23/03/16 11:32, David Vrabel wrote:
>>>> On 23/03/16 10:25, Jan Beulich wrote:
>>>>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>>>>> 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).
>>>>> Well, in some of the cases feature flags only make sense for one
>>>>> kind of guest, so if such a flag is set it could be used as positive
>>>>> indication (while it being clear may then still mean nothing).
>>>>>
>>>>>> 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.
>>>>> That would seem a good idea to me. What do others, namely
>>>>> Linux maintainers, think?
>>>> What's the use case for user space knowing if it's in a PV or HVM domain?
>>> The first thing coming to my mind would be diagnostic tools.
>> Having the admin able to tell for informational purposes is useful.
>> They can find out by looking at the top of `dmesg`, but a hypervisor
>> sysfs node is cleaner than requiring the admin to know every printk()
>> variant that Xen puts out.
> Especially on a long running guest this information might be not
> available in case of trouble.

What about dmidecode?

Unprivileged PV guests will return nothing:

[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# dmidecode
# dmidecode 2.11
# No SMBIOS nor DMI entry point found, sorry.
[root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]#


HVM guests will say something like:

System Information
     Manufacturer: Xen
     Product Name: HVM domU

and dom0 will report actual info.

-boris

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

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

[Andrew Cooper]

On 23/03/16 10:25, Jan Beulich wrote:
>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>> 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).
> Well, in some of the cases feature flags only make sense for one
> kind of guest, so if such a flag is set it could be used as positive
> indication (while it being clear may then still mean nothing).
>
>> 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.
> That would seem a good idea to me. What do others, namely
> Linux maintainers, think?

I would recommend against differentiating hvm and pvh, especially as pvh
is being replaced with hvmlite.

If you want more generic terms which might be acceptable to Linux, how
about "ring deprivileged" (which applies to UML and Lguest), and
"hardware extensions"?

~Andrew

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

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

[Juergen Gross]

On 23/03/16 11:34, Andrew Cooper wrote:
> On 23/03/16 10:25, Jan Beulich wrote:
>>>>> On 23.03.16 at 11:14, <JGross@suse.com> wrote:
>>> 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).
>> Well, in some of the cases feature flags only make sense for one
>> kind of guest, so if such a flag is set it could be used as positive
>> indication (while it being clear may then still mean nothing).
>>
>>> 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.
>> That would seem a good idea to me. What do others, namely
>> Linux maintainers, think?
> 
> I would recommend against differentiating hvm and pvh, especially as pvh
> is being replaced with hvmlite.
> 
> If you want more generic terms which might be acceptable to Linux, how
> about "ring deprivileged" (which applies to UML and Lguest), and
> "hardware extensions"?

Before making such a move I think David's question should be answered
first.


Juergen


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

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

[Andrew Cooper]

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@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.

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@lists.xen.org
http://lists.xen.org/xen-devel