public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox