Hi Michael, On Tue, Mar 01, 2022 at 11:21:38AM -0500, Michael S. Tsirkin 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. In this way, the race would > > be entirely eliminated. We would then be able to propagate this outwards > > to other drivers, by just exporting an extern symbol, in the manner of > > `jiffies`, and propagate it upwards to userspace, by putting it in the > > vDSO, in the manner of gettimeofday. And like that, there'd be no > > terrible async thing and things would work pretty easily. > > I am not sure what the difference is though. So we have a 16 byte unique > value and you would prefer a dword counter. How is the former not a > superset of the later? Laszlo just asked the same question, which I answered here: <https://lore.kernel.org/lkml/Yh5JwK6toc%2FzBNL7@xxxxxxxxx/>. You have to read the full 16 bytes. You can't safely just read the first 4 or 8 or something, because it's a "unique ID" rather than a counter. That seems like a needlessly expensive thing to do on each-and-every packet. > I'm not sure how safe it is to expose it to > userspace specifically, but rest of text talks about exposing it to a > kernel driver so maybe not an issue? So what makes interrupt driven > required, and why not just remap and read existing vmgenid in the pull > manner? What did I miss? I don't really understand your question, but guessing your meaning: I'm not talking about exposing the actual 16-byte value to any other drivers, but just notifying them that their sessions should be dropped. If it's easier to think about this in code, grep for wg_pm_notification(), and consider that it'd be changing this code: if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE) return 0; into: if (action != PM_HIBERNATION_PREPARE && action != PM_SUSPEND_PREPARE && action != PM_VMFORK_POST) return 0; But perhaps I misunderstood this part of your question? Jason
