QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Alexander Graf <graf@amazon.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Jann Horn <jannh@google.com>
Cc: Willy Tarreau <w@1wt.eu>, Colm MacCarthaigh <colmmacc@amazon.com>,
	"Catangiu, Adrian Costin" <acatan@amazon.com>,
	Andy Lutomirski <luto@kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Eric Biggers <ebiggers@kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	 kernel list <linux-kernel@vger.kernel.org>,
	"open list:VIRTIO GPU DRIVER"
	"Woodhouse, David" <dwmw@amazon.co.uk>, <bonzini@gnu.org>,
	"Singh, Balbir" <sblbir@amazon.com>,
	"Weiss, Radu" <raduweis@amazon.com>, <oridgar@gmail.com>,
	<ghammer@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Qemu Developers" <qemu-devel@nongnu.org>,
	KVM list <kvm@vger.kernel.org>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	Linux API <linux-api@vger.kernel.org>, <mpe@ellerman.id.au>,
	linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
Date: Tue, 20 Oct 2020 11:54:56 +0200
Message-ID: <b2f8ecec-35e8-93c6-b4cb-bb89ee8baa2d@amazon.de> (raw)
In-Reply-To: <2e505365-db4a-6054-8bc8-f9a81978c6d4@de.ibm.com>

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.


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

  reply index

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AQHWo8lIfZnFKGe8nkGmhTCXwq5R3w==>
2020-10-16 14:33 ` Catangiu, Adrian Costin
2020-10-16 15:00   ` Catangiu, Adrian Costin
2020-10-16 15:14   ` gregkh
2020-10-17  1:40   ` Jann Horn
2020-10-17  3:36     ` Willy Tarreau
2020-10-17  4:02       ` Jann Horn
2020-10-17  4:34         ` Colm MacCarthaigh
2020-10-17  5:01           ` Jann Horn
2020-10-17  5:29             ` Colm MacCarthaigh
2020-10-17  5:37             ` Willy Tarreau
2020-10-17  5:52               ` Jann Horn
2020-10-17  6:44                 ` Willy Tarreau
2020-10-17  6:55                   ` Jann Horn
2020-10-17  7:17                     ` Willy Tarreau
2020-10-17 13:24                     ` Jason A. Donenfeld
2020-10-17 18:06                       ` Catangiu, Adrian Costin
2020-10-17 18:09                       ` Alexander Graf
2020-10-18  2:08                         ` Jann Horn
2020-10-20  9:35                         ` Christian Borntraeger
2020-10-20  9:54                           ` Alexander Graf [this message]
2020-10-20 16:54                         ` Catangiu, Adrian Costin
2020-10-18  3:14                       ` Colm MacCarthaigh
2020-10-18 15:52                       ` Michael S. Tsirkin
2020-10-18 15:54                         ` Andy Lutomirski
2020-10-18 15:59                           ` Michael S. Tsirkin
2020-10-18 16:14                             ` Andy Lutomirski
2020-10-19 15:00                               ` Michael S. Tsirkin
2020-10-17 18:10     ` Andy Lutomirski
2020-10-19 17:15       ` Mathieu Desnoyers
2020-10-20 10:00         ` Alexander Graf

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b2f8ecec-35e8-93c6-b4cb-bb89ee8baa2d@amazon.de \
    --to=graf@amazon.de \
    --cc=Jason@zx2c4.com \
    --cc=acatan@amazon.com \
    --cc=bonzini@gnu.org \
    --cc=borntraeger@de.ibm.com \
    --cc=colmmacc@amazon.com \
    --cc=corbet@lwn.net \
    --cc=dwmw@amazon.co.uk \
    --cc=ebiggers@kernel.org \
    --cc=ghammer@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=mst@redhat.com \
    --cc=oridgar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=qemu-devel@nongnu.org \
    --cc=raduweis@amazon.com \
    --cc=rafael@kernel.org \
    --cc=sblbir@amazon.com \
    --cc=tytso@mit.edu \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=w@1wt.eu \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git
	git clone --mirror https://lore.kernel.org/qemu-devel/2 qemu-devel/git/2.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git