Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

From: Alexander Graf
Date: Fri May 31 2019 - 05:30:40 EST



On 31.05.19 11:12, Raslan, KarimAllah wrote:
On Fri, 2019-05-31 at 11:06 +0200, Alexander Graf wrote:
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?

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

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 ...
How about "psci_ops.conduit" (PSCI_CONDUIT_HVC vs PSCI_CONDUIT_SMC)?


This won't work for 2 reasons:

 a) You don't know it's KVM. You only know you might be running in EL1.
 b) KVM may choose to just use SMC for PSCI going forward and trap on it.


Alex