All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: bchalios@amazon.es
Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, Jason@zx2c4.com,
	dwmw@amazon.co.uk, graf@amazon.de, xmarcalx@amazon.co.uk
Subject: Re: [PATCH 2/2] virt: vmgenid: add support for generation counter
Date: Wed, 3 Aug 2022 17:28:08 +0200	[thread overview]
Message-ID: <YuqUCPN11aSUmjDy@kroah.com> (raw)
In-Reply-To: <20220803152127.48281-3-bchalios@amazon.es>

On Wed, Aug 03, 2022 at 05:21:27PM +0200, bchalios@amazon.es wrote:
> From: Babis Chalios <bchalios@amazon.es>
> 
> VM Generation ID provides a means of reseeding kernel's RNG using a
> 128-bit UUID when a VM fork occurs, thus avoiding issues running
> multiple VMs with the exact same RNG state. However, user-space
> applications, such as user-space PRNGs and applications that maintain
> world-unique data, need a mechanism to handle VM fork events as well.
> 
> To handle the user-space use-case, this: <url> qemu patch extends
> Microsoft's original vmgenid specification adding an extra page which
> holds a single 32-bit generation counter, which increases every time a
> VM gets restored from a snapshot.
> 
> This patch exposes the generation counter through a character device
> (`/dev/vmgenid`) that provides a `read` and `mmap` interface, for
> user-space applications to consume. Userspace applications should read
> this value before starting a transaction involving cached random bits
> and ensure that it has not changed while committing the transaction.
> 
> It can be used from qemu using the `-device vmgenid,guid=auto,genctr=42`
> parameter to start a VM with a generation counter with value 42.
> Reading 4 bytes from `/dev/vmgenid` will return the value 42. Next, use
> `savevm my_snapshot` in the monitor to snapshot the VM. Now, start
> another VM using `-device vmgenid,guid=auto,genctr=43 -loadvm
> my_snapshot`. Reading now from `/dev/vmgenid` will return 43.
> 
> Signed-off-by: Babis Chalios <bchalios@amazon.es>
> ---
>  Documentation/virt/vmgenid.rst | 120 +++++++++++++++++++++++++++++++++
>  drivers/virt/vmgenid.c         | 103 +++++++++++++++++++++++++++-
>  2 files changed, 221 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/virt/vmgenid.rst
> 
> diff --git a/Documentation/virt/vmgenid.rst b/Documentation/virt/vmgenid.rst
> new file mode 100644
> index 000000000..61c29e4a7
> --- /dev/null
> +++ b/Documentation/virt/vmgenid.rst
> @@ -0,0 +1,120 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=======
> +VMGENID
> +=======

<snip>

This file is now just floating in the directory, not tied to anything,
so auto-generation of the documentation will not pick it up or link to
it, right?

So, why does this have to be a separate file at all?  Why not put this
in the .c file and pull it straight from there so that it keeps in sync
with the code easier?

thanks,

greg k-h

  reply	other threads:[~2022-08-03 15:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-03 15:21 [PATCH 0/2] virt: vmgenid: add generation counter bchalios
2022-08-03 15:21 ` [PATCH 1/2] virt: vmgenid: add helper function to parse ADDR bchalios
2022-08-03 15:21 ` [PATCH 2/2] virt: vmgenid: add support for generation counter bchalios
2022-08-03 15:28   ` Greg KH [this message]
2022-08-03 15:30   ` Greg KH
2022-08-03 17:53     ` Chalios, Babis
2022-08-03 15:31   ` Greg KH
2022-08-03 17:58     ` Chalios, Babis
2022-08-14  3:26   ` kernel test robot
2022-08-03 15:50 ` [PATCH 0/2] virt: vmgenid: add " Chalios, Babis
2022-08-03 15:57 ` Chalios, Babis
2022-08-04 13:33 ` Chalios, Babis
2022-08-04 14:59 ` Jason A. Donenfeld
2022-08-04 15:46   ` bchalios
2022-08-10  9:19   ` bchalios

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=YuqUCPN11aSUmjDy@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Jason@zx2c4.com \
    --cc=bchalios@amazon.es \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=xmarcalx@amazon.co.uk \
    /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: link
Be 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.