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
