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

[Juergen Gross <jgross@suse.com>]

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