Re: [PATCH 2/2] show hypervisor information on sysfs
On Tue, 10 Feb 2009 11:20:23 -0200 Glauber Costa wrote: > > Anyway, just wanted to make you aware of what might come next. > > Why wouldn't it be extensible? So far, I've only added an attribute. But we > can easily add others, and directories with even more attributes if we must. Oh, sure it's easily extensible, the question is if the first attribute you now add will be at the right place. That is: is all information about the 1st level hypervisor supposed to be found in /sys/hypervisor or should it be in a subdirectory? E.g. /sys/hypervisor/level1 or something like that. But adding your attribute won't hurt. The worst case is that it gets duplicated. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] show hypervisor information on sysfs
On Sat, Feb 07, 2009 at 11:43:31AM +0100, Heiko Carstens wrote: > On Fri, 6 Feb 2009 10:46:57 -0500 > Glauber Costa wrote: > > > It is useful to easily grab information about whether or not > > we're running on top of a hypervisor. And in case affirmative, > > which one. > > > > This patch shows it in /sys/hypervisor (and as a site effect, allow > > it to be directly selectable). > > Not really an objection, but is this really easily extensible? Next > thing people are going to ask: how many cpus does my hypervisor have? > Is my hypervisor running itself within a hypervisor and how many cpus > does that have? etc. > > Maybe some directory structure for each hypervisor level would be nice? > > Just to get a feeling for what will come up next: on s390 we have the > file /proc/sysinfo which contains a lot of information about all > underlying hypervisors: > > Manufacturer: IBM > Type: 2097 > Model:724 E26 > Sequence Code:0003C03F > Plant:02 > Model Capacity: 724 1748 > Model Perm. Capacity: 724 1748 > Model Temp. Capacity: 724 1748 > > CPUs Total: 28 > CPUs Configured: 24 > CPUs Standby: 0 > CPUs Reserved:4 > Capability: 904 1350 > Adjustment 02-way:61500 61500 > Adjustment 03-way:59260 59500 > Adjustment 04-way:57480 57300 > Adjustment 05-way:55800 55700 > Adjustment 06-way:54700 54300 > Adjustment 07-way:53600 53100 > Adjustment 08-way:52500 52040 > Adjustment 09-way:51200 51000 > Adjustment 10-way:50100 5 > Adjustment 11-way:49000 49020 > Adjustment 12-way:48000 48120 > Adjustment 13-way:47200 47300 > Adjustment 14-way:46400 46500 > Adjustment 15-way:45600 45800 > Adjustment 16-way:44800 45200 > Adjustment 17-way:44300 44680 > Adjustment 18-way:43900 44120 > Adjustment 19-way:43500 43640 > Adjustment 20-way:43100 43200 > Adjustment 21-way:42600 42740 > Adjustment 22-way:42300 42360 > Adjustment 23-way:42000 41980 > Adjustment 24-way:41700 41600 > Adjustment 25-way:41400 41240 > Adjustment 26-way:41100 40960 > Adjustment 27-way:40800 40680 > Adjustment 28-way:40400 40360 > Secondary Capability: 904 > > LPAR Number: 47 > LPAR Characteristics: Shared > LPAR Name:H42LP45 > LPAR Adjustment: 500 > LPAR CPUs Total: 16 > LPAR CPUs Configured: 12 > LPAR CPUs Standby:4 > LPAR CPUs Reserved: 0 > LPAR CPUs Dedicated: 0 > LPAR CPUs Shared: 12 > > VM00 Name:H4245004 > VM00 Control Program: z/VM5.3.0 > VM00 Adjustment: 250 > VM00 CPUs Total: 3 > VM00 CPUs Configured: 3 > VM00 CPUs Standby:0 > VM00 CPUs Reserved: 0 > > Besides a lot of other stuff this tells you that my guest is running on > 28 cpu machine (24 cpus active), that my guest is running in logical > partition 47, which has 16 cpus of which 12 are used. Within that > logical partition my hypervisor is running (z/VM 5.3.0). And finally it > tells you my guest (H4245004) has three cpus (cpus that you're going to > see in /proc/cpuinfo). > > Oh, and before somebody asks: yes, we do have an instruction to get all > of this information ;) errr... I imagined you did. s390 is the closest architecture to get a dwiw instruction in the planet. > > Anyway, just wanted to make you aware of what might come next. Why wouldn't it be extensible? So far, I've only added an attribute. But we can easily add others, and directories with even more attributes if we must. > why not simply: > > return sysfs_create_file(hypervisor_kobj, &hyper_name_attr.attr); > > If it fails the sysfs code hopefully will dump something on the > console. We shouldn't add a printk for each and every sysfs_create_file > that might fail. It's just overkill. agreed. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] show hypervisor information on sysfs
On Fri, 6 Feb 2009 10:46:57 -0500 Glauber Costa wrote: > It is useful to easily grab information about whether or not > we're running on top of a hypervisor. And in case affirmative, > which one. > > This patch shows it in /sys/hypervisor (and as a site effect, allow > it to be directly selectable). Not really an objection, but is this really easily extensible? Next thing people are going to ask: how many cpus does my hypervisor have? Is my hypervisor running itself within a hypervisor and how many cpus does that have? etc. Maybe some directory structure for each hypervisor level would be nice? Just to get a feeling for what will come up next: on s390 we have the file /proc/sysinfo which contains a lot of information about all underlying hypervisors: Manufacturer: IBM Type: 2097 Model:724 E26 Sequence Code:0003C03F Plant:02 Model Capacity: 724 1748 Model Perm. Capacity: 724 1748 Model Temp. Capacity: 724 1748 CPUs Total: 28 CPUs Configured: 24 CPUs Standby: 0 CPUs Reserved:4 Capability: 904 1350 Adjustment 02-way:61500 61500 Adjustment 03-way:59260 59500 Adjustment 04-way:57480 57300 Adjustment 05-way:55800 55700 Adjustment 06-way:54700 54300 Adjustment 07-way:53600 53100 Adjustment 08-way:52500 52040 Adjustment 09-way:51200 51000 Adjustment 10-way:50100 5 Adjustment 11-way:49000 49020 Adjustment 12-way:48000 48120 Adjustment 13-way:47200 47300 Adjustment 14-way:46400 46500 Adjustment 15-way:45600 45800 Adjustment 16-way:44800 45200 Adjustment 17-way:44300 44680 Adjustment 18-way:43900 44120 Adjustment 19-way:43500 43640 Adjustment 20-way:43100 43200 Adjustment 21-way:42600 42740 Adjustment 22-way:42300 42360 Adjustment 23-way:42000 41980 Adjustment 24-way:41700 41600 Adjustment 25-way:41400 41240 Adjustment 26-way:41100 40960 Adjustment 27-way:40800 40680 Adjustment 28-way:40400 40360 Secondary Capability: 904 LPAR Number: 47 LPAR Characteristics: Shared LPAR Name:H42LP45 LPAR Adjustment: 500 LPAR CPUs Total: 16 LPAR CPUs Configured: 12 LPAR CPUs Standby:4 LPAR CPUs Reserved: 0 LPAR CPUs Dedicated: 0 LPAR CPUs Shared: 12 VM00 Name:H4245004 VM00 Control Program: z/VM5.3.0 VM00 Adjustment: 250 VM00 CPUs Total: 3 VM00 CPUs Configured: 3 VM00 CPUs Standby:0 VM00 CPUs Reserved: 0 Besides a lot of other stuff this tells you that my guest is running on 28 cpu machine (24 cpus active), that my guest is running in logical partition 47, which has 16 cpus of which 12 are used. Within that logical partition my hypervisor is running (z/VM 5.3.0). And finally it tells you my guest (H4245004) has three cpus (cpus that you're going to see in /proc/cpuinfo). Oh, and before somebody asks: yes, we do have an instruction to get all of this information ;) Anyway, just wanted to make you aware of what might come next. > int __init hypervisor_init(void) > { > + int ret; > hypervisor_kobj = kobject_create_and_add("hypervisor", NULL); > if (!hypervisor_kobj) > return -ENOMEM; > + > + ret = sysfs_create_file(hypervisor_kobj, &hyper_name_attr.attr); > + if (ret) { > + printk(KERN_WARNING "could not create hyper_name file\n"); > + return ret; > + } > + > return 0; > } why not simply: return sysfs_create_file(hypervisor_kobj, &hyper_name_attr.attr); If it fails the sysfs code hopefully will dump something on the console. We shouldn't add a printk for each and every sysfs_create_file that might fail. It's just overkill. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] show hypervisor information on sysfs
It is useful to easily grab information about whether or not we're running on top of a hypervisor. And in case affirmative, which one. This patch shows it in /sys/hypervisor (and as a site effect, allow it to be directly selectable). Signed-off-by: Glauber Costa --- arch/x86/include/asm/hypervisor.h |1 + arch/x86/kernel/cpu/hypervisor.c |2 ++ drivers/base/Kconfig |2 +- drivers/base/hypervisor.c | 34 ++ 4 files changed, 38 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h index 369f5c5..5a9cc18 100644 --- a/arch/x86/include/asm/hypervisor.h +++ b/arch/x86/include/asm/hypervisor.h @@ -22,5 +22,6 @@ extern unsigned long get_hypervisor_tsc_freq(void); extern void init_hypervisor(struct cpuinfo_x86 *c); +extern void set_hypervisor_name(const char *name); #endif diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c index ee1b228..29cf98c 100644 --- a/arch/x86/kernel/cpu/hypervisor.c +++ b/arch/x86/kernel/cpu/hypervisor.c @@ -31,8 +31,10 @@ detect_hypervisor_vendor(struct cpuinfo_x86 *c) { if (vmware_platform()) { c->x86_hyper_vendor = X86_HYPER_VENDOR_VMWARE; + set_hypervisor_name("VMware"); } else if (kvm_para_available()) { c->x86_hyper_vendor = X86_HYPER_VENDOR_KVM; + set_hypervisor_name("KVM"); } else { c->x86_hyper_vendor = X86_HYPER_VENDOR_NONE; } diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 8f006f9..209e03a 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -123,7 +123,7 @@ config DEBUG_DEVRES If you are unsure about this, Say N here. config SYS_HYPERVISOR - bool + bool "/sys/hypervisor interface" default n endmenu diff --git a/drivers/base/hypervisor.c b/drivers/base/hypervisor.c index 6428cba..dcf6f25 100644 --- a/drivers/base/hypervisor.c +++ b/drivers/base/hypervisor.c @@ -4,6 +4,7 @@ * Copyright (C) IBM Corp. 2006 * Copyright (C) 2007 Greg Kroah-Hartman * Copyright (C) 2007 Novell Inc. + * Copyright (C) 2009 Glauber Costa, Red Hat Inc. * * This file is released under the GPLv2 */ @@ -15,10 +16,43 @@ struct kobject *hypervisor_kobj; EXPORT_SYMBOL_GPL(hypervisor_kobj); +static const char *hv_string; + +static inline const char *get_hypervisor_name(void) +{ + if (!hv_string) + return "none"; + else + return hv_string; +} + +void set_hypervisor_name(const char *name) +{ + hv_string = name; +} + +static ssize_t hyper_name_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) +{ + return snprintf(buf, PAGE_SIZE, "%s\n", get_hypervisor_name()); +} + +static struct kobj_attribute hyper_name_attr = + __ATTR(hypervisor_name, S_IRUGO, hyper_name_show, NULL); + + int __init hypervisor_init(void) { + int ret; hypervisor_kobj = kobject_create_and_add("hypervisor", NULL); if (!hypervisor_kobj) return -ENOMEM; + + ret = sysfs_create_file(hypervisor_kobj, &hyper_name_attr.attr); + if (ret) { + printk(KERN_WARNING "could not create hyper_name file\n"); + return ret; + } + return 0; } -- 1.5.6.5 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html