From: "Sironi, Filippo" <sironi@amazon.de> To: "Graf, Alexander" <graf@amazon.com> Cc: LKML <linux-kernel@vger.kernel.org>, KVM list <kvm@vger.kernel.org>, Christian Borntraeger <borntraeger@de.ibm.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, "cohuck@redhat.com" <cohuck@redhat.com>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org> Subject: Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries Date: Fri, 17 May 2019 15:41:39 +0000 [thread overview] Message-ID: <3D2C4EE3-1C2E-4032-9964-31A066E542AA@amazon.de> (raw) In-Reply-To: <e976f31b-2ccd-29ba-6a32-2edde49f867f@amazon.com> > On 16. May 2019, at 15:50, Graf, Alexander <graf@amazon.com> 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@amazon.de> > > 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? > > Alex This 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 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. 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); Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
WARNING: multiple messages have this Message-ID (diff)
From: "Sironi, Filippo" <sironi@amazon.de> To: "Graf, Alexander" <graf@amazon.com> Cc: KVM list <kvm@vger.kernel.org>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "cohuck@redhat.com" <cohuck@redhat.com>, LKML <linux-kernel@vger.kernel.org>, Christian Borntraeger <borntraeger@de.ibm.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com> Subject: Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries Date: Fri, 17 May 2019 15:41:39 +0000 [thread overview] Message-ID: <3D2C4EE3-1C2E-4032-9964-31A066E542AA@amazon.de> (raw) In-Reply-To: <e976f31b-2ccd-29ba-6a32-2edde49f867f@amazon.com> > On 16. May 2019, at 15:50, Graf, Alexander <graf@amazon.com> 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@amazon.de> > > 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? > > Alex This 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 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. 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); Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich Ust-ID: DE 289 237 879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-17 15:41 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-09 9:54 [PATCH] KVM: Start populating /sys/hypervisor with KVM entries Filippo Sironi 2018-10-09 10:41 ` Christian Borntraeger 2018-10-09 16:21 ` Boris Ostrovsky 2018-10-09 16:21 ` Boris Ostrovsky 2018-10-09 17:50 ` Cornelia Huck 2018-10-09 17:50 ` Cornelia Huck 2018-10-09 15:00 ` Konrad Rzeszutek Wilk 2018-10-10 5:19 ` kbuild test robot 2019-05-14 15:16 ` Filippo Sironi 2019-05-14 15:16 ` [Xen-devel] " Filippo Sironi 2019-05-14 15:16 ` [PATCH v2 1/2] " Filippo Sironi 2019-05-14 15:16 ` [Xen-devel] " Filippo Sironi 2019-05-14 15:26 ` Christian Borntraeger 2019-05-14 15:26 ` [Xen-devel] " Christian Borntraeger 2019-05-14 16:09 ` Sironi, Filippo 2019-05-14 16:09 ` Sironi, Filippo 2019-05-14 16:09 ` [Xen-devel] " Sironi, Filippo 2019-05-14 16:31 ` Christian Borntraeger 2019-05-14 16:31 ` Christian Borntraeger 2019-05-14 16:31 ` [Xen-devel] " Christian Borntraeger 2019-05-14 22:08 ` Sironi, Filippo 2019-05-14 22:08 ` Sironi, Filippo 2019-05-14 22:08 ` [Xen-devel] " Sironi, Filippo 2019-05-14 15:26 ` Christian Borntraeger 2019-05-16 13:50 ` Alexander Graf 2019-05-16 13:50 ` [Xen-devel] " Alexander Graf 2019-05-16 14:02 ` Andrew Cooper 2019-05-16 14:02 ` Andrew Cooper 2019-05-16 14:02 ` Andrew Cooper 2019-05-16 14:08 ` Alexander Graf 2019-05-16 14:08 ` [Xen-devel] " Alexander Graf 2019-05-16 14:08 ` Alexander Graf 2019-05-16 15:02 ` Boris Ostrovsky 2019-05-16 15:02 ` Boris Ostrovsky 2019-05-16 15:14 ` Sironi, Filippo 2019-05-16 15:14 ` [Xen-devel] " Sironi, Filippo 2019-05-16 15:14 ` Sironi, Filippo 2019-05-16 15:02 ` Boris Ostrovsky 2019-05-17 15:41 ` Sironi, Filippo [this message] 2019-05-17 15:41 ` [Xen-devel] " Sironi, Filippo 2019-05-31 9:06 ` Alexander Graf 2019-05-31 9:06 ` [Xen-devel] " Alexander Graf 2019-05-31 9:12 ` Raslan, KarimAllah 2019-05-31 9:12 ` [Xen-devel] " Raslan, KarimAllah 2019-05-31 9:26 ` Alexander Graf 2019-05-31 9:26 ` [Xen-devel] " Alexander Graf 2019-05-31 9:26 ` Alexander Graf 2019-05-31 9:38 ` Marc Zyngier 2019-05-31 9:38 ` [Xen-devel] " Marc Zyngier 2019-05-31 9:38 ` Marc Zyngier 2019-05-31 9:12 ` Raslan, KarimAllah 2019-05-31 9:06 ` Alexander Graf 2019-05-17 15:41 ` Sironi, Filippo 2019-05-16 13:50 ` Alexander Graf 2019-05-14 15:16 ` Filippo Sironi 2019-05-14 15:16 ` [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID Filippo Sironi 2019-05-14 15:16 ` [Xen-devel] " Filippo Sironi 2019-05-16 13:56 ` Alexander Graf 2019-05-16 13:56 ` [Xen-devel] " Alexander Graf 2019-05-16 15:25 ` Sironi, Filippo 2019-05-16 15:25 ` [Xen-devel] " Sironi, Filippo 2019-05-16 15:33 ` Alexander Graf 2019-05-16 15:33 ` [Xen-devel] " Alexander Graf 2019-05-16 16:40 ` Boris Ostrovsky 2019-05-16 16:40 ` [Xen-devel] " Boris Ostrovsky 2019-05-16 17:41 ` Sironi, Filippo 2019-05-16 17:41 ` [Xen-devel] " Sironi, Filippo 2019-05-16 17:49 ` Alexander Graf 2019-05-16 17:49 ` [Xen-devel] " Alexander Graf 2019-05-16 17:49 ` Alexander Graf 2019-05-16 17:41 ` Sironi, Filippo 2019-05-16 16:40 ` Boris Ostrovsky 2019-05-16 15:33 ` Alexander Graf 2019-05-16 15:25 ` Sironi, Filippo 2019-05-16 13:56 ` Alexander Graf 2019-05-14 15:16 ` Filippo Sironi 2019-05-14 15:16 ` KVM: Start populating /sys/hypervisor with KVM entries Filippo Sironi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3D2C4EE3-1C2E-4032-9964-31A066E542AA@amazon.de \ --to=sironi@amazon.de \ --cc=boris.ostrovsky@oracle.com \ --cc=borntraeger@de.ibm.com \ --cc=cohuck@redhat.com \ --cc=graf@amazon.com \ --cc=konrad.wilk@oracle.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.