lkml.org 
[lkml]   [2022]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: propagating vmgenid outward and upward
Hi Laszlo,

On Tue, Mar 01, 2022 at 05:15:21PM +0100, Laszlo Ersek wrote:
> > If we had a "pull" model, rather than just expose a 16-byte unique
> > identifier, the vmgenid virtual hardware would _also_ expose a
> > word-sized generation counter, which would be incremented every time the
> > unique ID changed. Then, every time we would touch the RNG, we'd simply
> > do an inexpensive check of this memremap()'d integer, and reinitialize
> > with the unique ID if the integer changed.
>
> Does the vmgenid spec (as-is) preclude the use of the 16-byte identifier
> like this?
>
> After all, once you locate the identifier via the ADDR object, you could
> perhaps consult it every time you were about to touch the RNG.

No, you could in fact do this, and there'd be nothing wrong with that
from a spec perspective. You could even vDSO it all the way through
onward to userspace. However, doing a 16-byte atomic memcmp on
each-and-every packet is really a non-starter. For that kind of "check
it in the hot path" thing to be viable, you really want it to be a
counter that is word-sized. The "pull"-model involves pulling on every
single packet in order to be better than the "push"-model. Anyway, even
with a word-sized counter, it's unclear whether the costs of checking on
every packet would be worth it to everyone, but at least it's more
tenable than a 16-byte whammy.

Jason

\
 
 \ /
  Last update: 2022-03-01 17:29    [W:0.137 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site