From: Mike Rapoport <rppt@kernel.org> To: Alexander Graf <graf@amazon.de> Cc: Christian Borntraeger <borntraeger@de.ibm.com>, "Catangiu, Adrian Costin" <acatan@amazon.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>, Jann Horn <jannh@google.com>, Willy Tarreau <w@1wt.eu>, "MacCarthaigh, Colm" <colmmacc@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>, "Woodhouse, David" <dwmw@amazon.co.uk>, "bonzini@gnu.org" <bonzini@gnu.org>, "Singh, Balbir" <sblbir@amazon.com>, "Weiss, Radu" <raduweis@amazon.com>, "oridgar@gmail.com" <oridgar@gmail.com>, "ghammer@redhat.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" <mpe@ellerman.id.au>, linux-s390 <linux-s390@vger.kernel.org>, "areber@redhat.com" <areber@redhat.com>, Pavel Emelyanov <ovzxemul@gmail.com>, Andrey Vagin <avagin@gmail.com>, Dmitry Safonov <0x7f454c46@gmail.com>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, "gil@azul.com" <gil@azul.com>, "asmehra@redhat.com" <asmehra@redhat.com>, "dgunigun@redhat.com" <dgunigun@redhat.com>, "vijaysun@ca.ibm.com" <vijaysun@ca.ibm.com> Subject: Re: [PATCH v2] drivers/virt: vmgenid: add vm generation id driver Date: Thu, 19 Nov 2020 19:38:00 +0200 [thread overview] Message-ID: <20201119173800.GD8537@kernel.org> (raw) In-Reply-To: <da1a1fa7-a1de-d0e6-755b-dd587687765e@amazon.de> On Thu, Nov 19, 2020 at 01:51:18PM +0100, Alexander Graf wrote: > > > On 19.11.20 13:02, Christian Borntraeger wrote: > > > > On 16.11.20 16:34, Catangiu, Adrian Costin wrote: > > > - Background > > > > > > The VM Generation ID is a feature defined by Microsoft (paper: > > > http://go.microsoft.com/fwlink/?LinkId=260709) and supported by > > > multiple hypervisor vendors. > > > > > > The feature is required in virtualized environments by apps that work > > > with local copies/caches of world-unique data such as random values, > > > uuids, monotonically increasing counters, etc. > > > Such apps can be negatively affected by VM snapshotting when the VM > > > is either cloned or returned to an earlier point in time. > > > > > > The VM Generation ID is a simple concept meant to alleviate the issue > > > by providing a unique ID that changes each time the VM is restored > > > from a snapshot. The hw provided UUID value can be used to > > > differentiate between VMs or different generations of the same VM. > > > > > > - Problem > > > > > > The VM Generation ID is exposed through an ACPI device by multiple > > > hypervisor vendors but neither the vendors or upstream Linux have no > > > default driver for it leaving users to fend for themselves. > > > > I see that the qemu implementation is still under discussion. What is > > Uh, the ACPI Vmgenid device emulation is in QEMU since 2.9.0 :). > > > the status of the other existing implementations. Do they already exist? > > In other words is ACPI a given? > > I think the majority of this driver could be used with just a different > > backend for platforms without ACPI so in any case we could factor out > > the backend (acpi, virtio, whatever) but if we are open we could maybe > > start with something else. > > I agree 100%. I don't think we really need a new framework in the kernel for > that. We can just have for example an s390x specific driver that also > provides the same notification mechanism through a device node that is also > named "/dev/vmgenid", no? > > Or alternatively we can split the generic part of this driver as soon as a > second one comes along and then have both driver include that generic logic. > > The only piece where I'm unsure is how this will interact with CRIU. To C/R applications that use /dev/vmgenid CRIU need to be aware of it. Checkpointing and restoring withing the same "VM generation" shouldn't be a problem, but IMHO, making restore work after genid bump could be challenging. Alex, what scenario involving CRIU did you have in mind? > Can containers emulate ioctls and device nodes? Containers do not emulate ioctls but they can have /dev/vmgenid inside the container, so applications can use it the same way as outside the container. > Alex -- Sincerely yours, Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org> To: Alexander Graf <graf@amazon.de> Cc: "asmehra@redhat.com" <asmehra@redhat.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>, "dgunigun@redhat.com" <dgunigun@redhat.com>, KVM list <kvm@vger.kernel.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, "ghammer@redhat.com" <ghammer@redhat.com>, "vijaysun@ca.ibm.com" <vijaysun@ca.ibm.com>, "Weiss, Radu" <raduweis@amazon.com>, Qemu Developers <qemu-devel@nongnu.org>, Michal Hocko <mhocko@kernel.org>, Andrey Vagin <avagin@gmail.com>, Pavel Machek <pavel@ucw.cz>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, linux-s390 <linux-s390@vger.kernel.org>, Jonathan Corbet <corbet@lwn.net>, "mpe@ellerman.id.au" <mpe@ellerman.id.au>, "Michael S. Tsirkin" <mst@redhat.com>, Eric Biggers <ebiggers@kernel.org>, Christian Borntraeger <borntraeger@de.ibm.com>, "Singh, Balbir" <sblbir@amazon.com>, "bonzini@gnu.org" <bonzini@gnu.org>, Jann Horn <jannh@google.com>, Dmitry Safonov <0x7f454c46@gmail.com>, "oridgar@gmail.com" <oridgar@gmail.com>, "Catangiu, Adrian Costin" <acatan@amazon.com>, Andy Lutomirski <luto@kernel.org>, "gil@azul.com" <gil@azul.com>, "MacCarthaigh, Colm" <colmmacc@amazon.com>, "Theodore Y. Ts'o" <tytso@mit.edu>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "areber@redhat.com" <areber@redhat.com>, kernel list <linux-kernel@vger.kernel.org>, Pavel Emelyanov <ovzxemul@gmail.com>, Linux API <linux-api@vger.kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Willy Tarreau <w@1wt.eu>, "Woodhouse, David" <dwmw@amazon.co.uk> Subject: Re: [PATCH v2] drivers/virt: vmgenid: add vm generation id driver Date: Thu, 19 Nov 2020 19:38:00 +0200 [thread overview] Message-ID: <20201119173800.GD8537@kernel.org> (raw) In-Reply-To: <da1a1fa7-a1de-d0e6-755b-dd587687765e@amazon.de> On Thu, Nov 19, 2020 at 01:51:18PM +0100, Alexander Graf wrote: > > > On 19.11.20 13:02, Christian Borntraeger wrote: > > > > On 16.11.20 16:34, Catangiu, Adrian Costin wrote: > > > - Background > > > > > > The VM Generation ID is a feature defined by Microsoft (paper: > > > http://go.microsoft.com/fwlink/?LinkId=260709) and supported by > > > multiple hypervisor vendors. > > > > > > The feature is required in virtualized environments by apps that work > > > with local copies/caches of world-unique data such as random values, > > > uuids, monotonically increasing counters, etc. > > > Such apps can be negatively affected by VM snapshotting when the VM > > > is either cloned or returned to an earlier point in time. > > > > > > The VM Generation ID is a simple concept meant to alleviate the issue > > > by providing a unique ID that changes each time the VM is restored > > > from a snapshot. The hw provided UUID value can be used to > > > differentiate between VMs or different generations of the same VM. > > > > > > - Problem > > > > > > The VM Generation ID is exposed through an ACPI device by multiple > > > hypervisor vendors but neither the vendors or upstream Linux have no > > > default driver for it leaving users to fend for themselves. > > > > I see that the qemu implementation is still under discussion. What is > > Uh, the ACPI Vmgenid device emulation is in QEMU since 2.9.0 :). > > > the status of the other existing implementations. Do they already exist? > > In other words is ACPI a given? > > I think the majority of this driver could be used with just a different > > backend for platforms without ACPI so in any case we could factor out > > the backend (acpi, virtio, whatever) but if we are open we could maybe > > start with something else. > > I agree 100%. I don't think we really need a new framework in the kernel for > that. We can just have for example an s390x specific driver that also > provides the same notification mechanism through a device node that is also > named "/dev/vmgenid", no? > > Or alternatively we can split the generic part of this driver as soon as a > second one comes along and then have both driver include that generic logic. > > The only piece where I'm unsure is how this will interact with CRIU. To C/R applications that use /dev/vmgenid CRIU need to be aware of it. Checkpointing and restoring withing the same "VM generation" shouldn't be a problem, but IMHO, making restore work after genid bump could be challenging. Alex, what scenario involving CRIU did you have in mind? > Can containers emulate ioctls and device nodes? Containers do not emulate ioctls but they can have /dev/vmgenid inside the container, so applications can use it the same way as outside the container. > Alex -- Sincerely yours, Mike.
next prev parent reply other threads:[~2020-11-19 17:40 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-16 15:34 [PATCH v2] drivers/virt: vmgenid: add vm generation id driver Catangiu, Adrian Costin 2020-11-18 10:30 ` Alexander Graf 2020-11-27 17:17 ` Catangiu, Adrian Costin 2020-12-07 13:23 ` Alexander Graf 2020-11-19 12:02 ` Christian Borntraeger 2020-11-19 12:02 ` Christian Borntraeger 2020-11-19 12:51 ` Alexander Graf 2020-11-19 13:09 ` Christian Borntraeger 2020-11-19 13:09 ` Christian Borntraeger 2020-11-19 17:38 ` Mike Rapoport [this message] 2020-11-19 17:38 ` Mike Rapoport 2020-11-19 18:36 ` Alexander Graf 2020-11-19 18:36 ` Alexander Graf 2020-11-20 21:18 ` Dmitry Safonov 2020-11-20 21:18 ` Dmitry Safonov 2020-11-20 21:18 ` Dmitry Safonov 2020-11-27 18:26 ` [PATCH v3] " Catangiu, Adrian Costin 2020-11-27 18:26 ` Catangiu, Adrian Costin 2020-11-28 10:16 ` Mike Rapoport 2020-11-28 10:16 ` Mike Rapoport 2020-11-28 10:16 ` Mike Rapoport 2020-12-01 18:00 ` Eric W. Biederman 2020-12-01 18:00 ` Eric W. Biederman 2020-12-01 18:00 ` Eric W. Biederman 2020-12-07 13:11 ` Alexander Graf 2020-12-07 13:11 ` Alexander Graf 2021-01-11 7:35 ` Catangiu, Adrian Costin via 2020-11-20 22:29 ` [PATCH v2] " Jann Horn 2020-11-20 22:29 ` Jann Horn 2020-11-27 18:22 ` Jann Horn 2020-11-27 18:22 ` Jann Horn 2020-11-27 19:04 ` Catangiu, Adrian Costin 2020-11-27 20:20 ` Jann Horn 2020-11-27 20:20 ` Jann Horn 2020-12-07 14:22 ` Alexander Graf 2020-12-07 14:22 ` 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201119173800.GD8537@kernel.org \ --to=rppt@kernel.org \ --cc=0x7f454c46@gmail.com \ --cc=Jason@zx2c4.com \ --cc=acatan@amazon.com \ --cc=areber@redhat.com \ --cc=asmehra@redhat.com \ --cc=avagin@gmail.com \ --cc=bonzini@gnu.org \ --cc=borntraeger@de.ibm.com \ --cc=colmmacc@amazon.com \ --cc=corbet@lwn.net \ --cc=dgunigun@redhat.com \ --cc=dwmw@amazon.co.uk \ --cc=ebiggers@kernel.org \ --cc=ghammer@redhat.com \ --cc=gil@azul.com \ --cc=graf@amazon.de \ --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=ovzxemul@gmail.com \ --cc=pavel@ucw.cz \ --cc=ptikhomirov@virtuozzo.com \ --cc=qemu-devel@nongnu.org \ --cc=raduweis@amazon.com \ --cc=rafael@kernel.org \ --cc=sblbir@amazon.com \ --cc=tytso@mit.edu \ --cc=vijaysun@ca.ibm.com \ --cc=w@1wt.eu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.