Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 20.10.20 11:35, Christian Borntraeger wrote:
On 17.10.20 20:09, Alexander Graf wrote:
Hi Jason,

On 17.10.20 15:24, Jason A. Donenfeld wrote:

After discussing this offline with Jann a bit, I have a few general
comments on the design of this.

First, the UUID communicated by the hypervisor should be consumed by
the kernel -- added as another input to the rng -- and then userspace

We definitely want a kernel internal notifier as well, yes :).

should be notified that it should reseed any userspace RNGs that it
may have, without actually communicating that UUID to userspace. IOW,

I also tend to agree that it makes sense to disconnect the actual UUID we receive from the notification to user space. This would allow us to create a generic mechanism for VM save/restore cycles across different hypervisors. Let me add PPC and s390x people to the CC list to see whether they have anything remotely similar to the VmGenID mechanism. For x86 and aarch64, the ACPI and memory based VmGenID implemented here is the most obvious option to implement IMHO. It's also already implemented in all major hypervisors.

Hmm, what we do have configurations (e.g. stfle bits) and we do have a notification mechanism via sclp that notifies guests when things change.
As of today neither KVM nor Linux implement the sclp change notification mechanism, but I do see value in such a thing.

stfle only stores architected CPU capabilities, no? The UUID is about uniquely identifying clones of the same base image, so they can reestablish their uniqueness.

That said, your interest means that there may be a mechanism on s390 one day, so we should think about making it more generic.



I agree with Jann there. Then, it's the functioning of this
notification mechanism to userspace that is interesting to me.

Absolutely! Please have a look at the previous discussion here:


https://lore.kernel.org/linux-pm/B7793B7A-3660-4769-9B9A-FFCF250728BB@xxxxxxxxxx/

The user space interface is absolutely what this is about.

Yes. Passing a notification to userspace is essential. Where I do not see a solution yet is the race between notification and
already running with the old knowledge.

With a post-mortem interface, we will always have a tiny race window. I'm not really convinced that this is a serious problem yet though.

In order to do extract anything off a virtual machine that was cloned, you need to communicate with it. If you for example stop the network link until all of this device's users have indicated they are finished adjusting, the race should be small enough for any practical purposes I can think of.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux