Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries
> On 16. May 2019, at 17:02, Boris Ostrovsky wrote: > > On 5/16/19 10:08 AM, Alexander Graf wrote: >> >> My point is mostly that we should be as common >> as possible when it comes to /sys/hypervisor, so that tools don't have >> to care about the HV they're working against. > > It might make sense to have a common sys-hypervisor.c file > (drivers/hypervisor/sys-hypervisor.c or some such), with > hypervisor-specific ops/callbacks/etc. > > -boris Yes, it definitely does. I would follow up with future patches to make it happen. Filippo 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
Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries
On 5/16/19 10:08 AM, Alexander Graf wrote: > > My point is mostly that we should be as common > as possible when it comes to /sys/hypervisor, so that tools don't have > to care about the HV they're working against. It might make sense to have a common sys-hypervisor.c file (drivers/hypervisor/sys-hypervisor.c or some such), with hypervisor-specific ops/callbacks/etc. -boris
Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries
On 16/05/2019 14:50, Alexander Graf 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
> 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
> "".
This string comes straight from Xen.
It was an effort to reduce the quantity of interesting fingerprintable
data accessable by default to unprivileged guests.
See
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=a2fc8d514df2b38c310d4f4432fe06520b0769ed
~Andrew
Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries
On 16.05.19 07:02, Andrew Cooper wrote:
> On 16/05/2019 14:50, Alexander Graf 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
>> 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
>> "".
> This string comes straight from Xen.
>
> It was an effort to reduce the quantity of interesting fingerprintable
> data accessable by default to unprivileged guests.
>
> See
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=a2fc8d514df2b38c310d4f4432fe06520b0769ed
What a great design :). My point is mostly that we should be as common
as possible when it comes to /sys/hypervisor, so that tools don't have
to care about the HV they're working against.
By being first to implement you just created precedence, so we
can either simulate the same behavor for KVM or be different. And since
commonality is good, I'd rather be the same.
That said, I couldn't find in the patdch above whether Xen even emits
for the uuid. Does it have that capability? If not, we may as
well go with (null).
Alex
