[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries
On 17.05.19 17:41, Sironi, Filippo wrote: On 16. May 2019, at 15:50, Graf, Alexander <graf@xxxxxxxxxx> wrote: On 14.05.19 08:16, Filippo Sironi wrote:Start populating /sys/hypervisor with KVM entries when we're running on KVM. This is to replicate functionality that's available when we're running on Xen. Start with /sys/hypervisor/uuid, which users prefer over /sys/devices/virtual/dmi/id/product_uuid as a way to recognize a virtual machine, since it's also available when running on Xen HVM and on Xen PV and, on top of that doesn't require root privileges by default. Let's create arch-specific hooks so that different architectures can provide different implementations. Signed-off-by: Filippo Sironi <sironi@xxxxxxxxx>I think this needs something akin to https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-hypervisor-xen to document which files are available.--- v2: * move the retrieval of the VM UUID out of uuid_show and into kvm_para_get_uuid, which is a weak function that can be overwritten drivers/Kconfig | 2 ++ drivers/Makefile | 2 ++ drivers/kvm/Kconfig | 14 ++++++++++++++ drivers/kvm/Makefile | 1 + drivers/kvm/sys-hypervisor.c | 30 ++++++++++++++++++++++++++++++ 5 files changed, 49 insertions(+) create mode 100644 drivers/kvm/Kconfig create mode 100644 drivers/kvm/Makefile create mode 100644 drivers/kvm/sys-hypervisor.c[...]+ +__weak const char *kvm_para_get_uuid(void) +{ + return NULL; +} + +static ssize_t uuid_show(struct kobject *obj, + struct kobj_attribute *attr, + char *buf) +{ + const char *uuid = kvm_para_get_uuid(); + return sprintf(buf, "%s\n", uuid);The usual return value for the Xen /sys/hypervisor interface is "<denied>". Wouldn't it make sense to follow that pattern for the KVM one too? Currently, if we can not determine the UUID this will just return (null). Otherwise, looks good to me. Are you aware of any other files we should provide? Also, is there any reason not to implement ARM as well while at it? AlexThis originated from a customer request that was using /sys/hypervisor/uuid. My guess is that we would want to expose "type" and "version" moving forward and that's when we hypervisor hooks will be useful on top of arch hooks. On a different note, any idea how to check whether the OS is running virtualized on KVM on ARM and ARM64? kvm_para_available() isn't an Yeah, ARM doesn't have any KVM PV FWIW. I also can't find any explicit hint passed into guests that we are indeed running in KVM. The closest thing I can see is the SMBIOS product identifier in QEMU which gets patched to "KVM Virtual Machine". Maybe we'll have to do with that for the sake of backwards compatibility ... option and the same is true for S390 where kvm_para_available() always returns true and it would even if a KVM enabled kernel would be running on bare metal. For s390, you can figure the topology out using the sthyi instruction. I'm not sure if there is a nice in-kernel API to leverage that though. In fact, kvm_para_available() probably should check sthyi output to determine whether we really can use it, no? Christian? Alex I think we will need another arch hook to call a function that says whether the OS is running virtualized on KVM.+} + +static struct kobj_attribute uuid = __ATTR_RO(uuid); + +static int __init uuid_init(void) +{ + if (!kvm_para_available()) + return 0; + return sysfs_create_file(hypervisor_kobj, &uuid.attr); +} + +device_initcall(uuid_init); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |