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

[Alexander Graf <graf@amazon.de>]

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@amazon.com/
>>
>> 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