Message ID | 1458719424-1287-1-git-send-email-jgross@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> 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
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
>>> 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
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
>>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>>> 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
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
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
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
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:
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(-)