All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Catangiu, Adrian Costin" <acatan@amazon.com>
Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"Graf (AWS), Alexander" <graf@amazon.de>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"0x7f454c46@gmail.com" <0x7f454c46@gmail.com>,
	"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
	"Jason@zx2c4.com" <Jason@zx2c4.com>,
	"jannh@google.com" <jannh@google.com>, "w@1wt.eu" <w@1wt.eu>,
	"MacCarthaigh, Colm" <colmmacc@amazon.com>,
	"luto@kernel.org" <luto@kernel.org>,
	"tytso@mit.edu" <tytso@mit.edu>,
	"ebiggers@kernel.org" <ebiggers@kernel.org>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	"bonzini@gnu.org" <bonzini@gnu.org>,
	"Singh, Balbir" <sblbir@amazon.com>,
	"Weiss, Radu" <raduweis@amazon.com>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"mhocko@kernel.org" <mhocko@kernel.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"pavel@ucw.cz" <pavel@ucw.cz>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
	"areber@redhat.com" <areber@redhat.com>,
	"ovzxemul@gmail.com" <ovzxemul@gmail.com>,
	"avagin@gmail.com" <avagin@gmail.com>,
	"ptikhomirov@virtuozzo.com" <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>,
	"oridgar@gmail.com" <oridgar@gmail.com>,
	"ghammer@redhat.com" <ghammer@redhat.com>
Subject: Re: [PATCH v4 0/2] System Generation ID driver and VMGENID backend
Date: Wed, 27 Jan 2021 07:47:17 -0500	[thread overview]
Message-ID: <20210127074549-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <9952EF0C-CD1D-4EDB-BAB8-21F72C0BF90D@amazon.com>

On Thu, Jan 21, 2021 at 10:28:16AM +0000, Catangiu, Adrian Costin wrote:
> On 12/01/2021, 14:49, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>     On Tue, Jan 12, 2021 at 02:15:58PM +0200, Adrian Catangiu wrote:
>     > The first patch in the set implements a device driver which exposes a
>     > read-only device /dev/sysgenid to userspace, which contains a
>     > monotonically increasing u32 generation counter. Libraries and
>     > applications are expected to open() the device, and then call read()
>     > which blocks until the SysGenId changes. Following an update, read()
>     > calls no longer block until the application acknowledges the new
>     > SysGenId by write()ing it back to the device. Non-blocking read() calls
>     > return EAGAIN when there is no new SysGenId available. Alternatively,
>     > libraries can mmap() the device to get a single shared page which
>     > contains the latest SysGenId at offset 0.
> 
>     Looking at some specifications, the gen ID might actually be located
>     at an arbitrary address. How about instead of hard-coding the offset,
>     we expose it e.g. in sysfs?
> 
> The functionality is split between SysGenID which exposes an internal u32
> counter to userspace, and an (optional) VmGenID backend which drives
> SysGenID generation changes based on hw vmgenid updates.
> 
> The hw UUID you're referring to (vmgenid) is not mmap-ed to userspace or
> otherwise exposed to userspace. It is only used internally by the vmgenid
> driver to find out about VM generation changes and drive the more generic
> SysGenID.
> 
> The SysGenID u32 monotonic increasing counter is the one that is mmaped to
> userspace, but it is a software counter. I don't see any value in using a dynamic
> offset in the mmaped page. Offset 0 is fast and easy and most importantly it is
> static so no need to dynamically calculate or find it at runtime.

Well you are burning a whole page on it, using an offset the page
can be shared with other functionality.

> Thanks,
> Adrian.
> 
> 
> 
> 
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Catangiu, Adrian Costin" <acatan@amazon.com>
Cc: "Jason@zx2c4.com" <Jason@zx2c4.com>,
	"dgunigun@redhat.com" <dgunigun@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"ghammer@redhat.com" <ghammer@redhat.com>,
	"vijaysun@ca.ibm.com" <vijaysun@ca.ibm.com>,
	"0x7f454c46@gmail.com" <0x7f454c46@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mhocko@kernel.org" <mhocko@kernel.org>,
	"oridgar@gmail.com" <oridgar@gmail.com>,
	"avagin@gmail.com" <avagin@gmail.com>,
	"pavel@ucw.cz" <pavel@ucw.cz>,
	"ptikhomirov@virtuozzo.com" <ptikhomirov@virtuozzo.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"ebiggers@kernel.org" <ebiggers@kernel.org>,
	"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
	"Singh, Balbir" <sblbir@amazon.com>,
	"bonzini@gnu.org" <bonzini@gnu.org>, "Graf \(AWS\),
	Alexander" <graf@amazon.de>, "arnd@arndb.de" <arnd@arndb.de>,
	"jannh@google.com" <jannh@google.com>,
	"Weiss, Radu" <raduweis@amazon.com>,
	"asmehra@redhat.com" <asmehra@redhat.com>,
	"rppt@kernel.org" <rppt@kernel.org>,
	"luto@kernel.org" <luto@kernel.org>,
	"gil@azul.com" <gil@azul.com>,
	"MacCarthaigh, Colm" <colmmacc@amazon.com>,
	"tytso@mit.edu" <tytso@mit.edu>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"areber@redhat.com" <areber@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"ovzxemul@gmail.com" <ovzxemul@gmail.com>, "w@1wt.eu" <w@1wt.eu>,
	"Woodhouse, David" <dwmw@amazon.co.uk>
Subject: Re: [PATCH v4 0/2] System Generation ID driver and VMGENID backend
Date: Wed, 27 Jan 2021 07:47:17 -0500	[thread overview]
Message-ID: <20210127074549-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <9952EF0C-CD1D-4EDB-BAB8-21F72C0BF90D@amazon.com>

On Thu, Jan 21, 2021 at 10:28:16AM +0000, Catangiu, Adrian Costin wrote:
> On 12/01/2021, 14:49, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>     On Tue, Jan 12, 2021 at 02:15:58PM +0200, Adrian Catangiu wrote:
>     > The first patch in the set implements a device driver which exposes a
>     > read-only device /dev/sysgenid to userspace, which contains a
>     > monotonically increasing u32 generation counter. Libraries and
>     > applications are expected to open() the device, and then call read()
>     > which blocks until the SysGenId changes. Following an update, read()
>     > calls no longer block until the application acknowledges the new
>     > SysGenId by write()ing it back to the device. Non-blocking read() calls
>     > return EAGAIN when there is no new SysGenId available. Alternatively,
>     > libraries can mmap() the device to get a single shared page which
>     > contains the latest SysGenId at offset 0.
> 
>     Looking at some specifications, the gen ID might actually be located
>     at an arbitrary address. How about instead of hard-coding the offset,
>     we expose it e.g. in sysfs?
> 
> The functionality is split between SysGenID which exposes an internal u32
> counter to userspace, and an (optional) VmGenID backend which drives
> SysGenID generation changes based on hw vmgenid updates.
> 
> The hw UUID you're referring to (vmgenid) is not mmap-ed to userspace or
> otherwise exposed to userspace. It is only used internally by the vmgenid
> driver to find out about VM generation changes and drive the more generic
> SysGenID.
> 
> The SysGenID u32 monotonic increasing counter is the one that is mmaped to
> userspace, but it is a software counter. I don't see any value in using a dynamic
> offset in the mmaped page. Offset 0 is fast and easy and most importantly it is
> static so no need to dynamically calculate or find it at runtime.

Well you are burning a whole page on it, using an offset the page
can be shared with other functionality.

> Thanks,
> Adrian.
> 
> 
> 
> 
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.



  reply	other threads:[~2021-01-27 12:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 12:15 [PATCH v4 0/2] System Generation ID driver and VMGENID backend Adrian Catangiu
2021-01-12 12:15 ` Adrian Catangiu via
2021-01-12 12:15 ` Adrian Catangiu
2021-01-12 12:15 ` [PATCH v4 1/2] drivers/misc: sysgenid: add system generation id driver Adrian Catangiu
2021-01-12 12:15   ` Adrian Catangiu via
2021-01-12 12:15   ` Adrian Catangiu
2021-01-12 13:08   ` Greg KH
2021-01-12 13:08     ` Greg KH
2021-01-21  9:54     ` Catangiu, Adrian Costin
2021-01-21  9:54       ` acatan--- via
2021-01-12 13:08   ` Michael S. Tsirkin
2021-01-12 13:08     ` Michael S. Tsirkin
2021-01-21 12:48     ` Catangiu, Adrian Costin
2021-01-21 12:48       ` acatan--- via
2021-01-19 22:34   ` Randy Dunlap
2021-01-19 22:34     ` Randy Dunlap
2021-01-27 22:15   ` Pavel Machek
2021-01-27 22:15     ` Pavel Machek
2021-02-02 14:32     ` Michael S. Tsirkin
2021-02-02 14:32       ` Michael S. Tsirkin
2021-01-12 12:16 ` [PATCH v4 2/2] drivers/virt: vmgenid: add vm " Adrian Catangiu
2021-01-12 12:16   ` Adrian Catangiu via
2021-01-12 12:16   ` Adrian Catangiu
2021-01-12 12:48 ` [PATCH v4 0/2] System Generation ID driver and VMGENID backend Michael S. Tsirkin
2021-01-12 12:48   ` Michael S. Tsirkin
2021-01-21 10:28   ` Catangiu, Adrian Costin
2021-01-21 10:28     ` acatan--- via
2021-01-27 12:47     ` Michael S. Tsirkin [this message]
2021-01-27 12:47       ` Michael S. Tsirkin
2021-01-28 12:58       ` Alexander Graf
2021-01-28 12:58         ` graf--- via
2021-02-02 14:34         ` Michael S. Tsirkin
2021-02-02 14:34           ` Michael S. Tsirkin

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=20210127074549-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=0x7f454c46@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=acatan@amazon.com \
    --cc=areber@redhat.com \
    --cc=arnd@arndb.de \
    --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=ebiederm@xmission.com \
    --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-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=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=rppt@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: 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.