[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: propagating vmgenid outward and upward
From: |
Jason A. Donenfeld |
Subject: |
Re: propagating vmgenid outward and upward |
Date: |
Tue, 1 Mar 2022 17:28:48 +0100 |
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
- propagating vmgenid outward and upward, Jason A. Donenfeld, 2022/03/01
- Re: propagating vmgenid outward and upward, Laszlo Ersek, 2022/03/01
- Re: propagating vmgenid outward and upward,
Jason A. Donenfeld <=
- Re: propagating vmgenid outward and upward, Michael S. Tsirkin, 2022/03/02
- Re: propagating vmgenid outward and upward, Jason A. Donenfeld, 2022/03/02
- Re: propagating vmgenid outward and upward, Michael S. Tsirkin, 2022/03/02
- Re: propagating vmgenid outward and upward, Jason A. Donenfeld, 2022/03/02
- Re: propagating vmgenid outward and upward, Michael S. Tsirkin, 2022/03/02
- Re: propagating vmgenid outward and upward, Jason A. Donenfeld, 2022/03/02