On Wed, Aug 03, 2022 at 03:41:45PM +0200, bchal...@amazon.es wrote: > From: Babis Chalios <bchal...@amazon.es> > > VM generation ID exposes a GUID inside the VM which changes every time a > VM restore is happening. Typically, this GUID is used by the guest > kernel to re-seed its internal PRNG. As a result, this value cannot be > exposed in guest user-space as a notification mechanism for VM restore > events. > > This patch set extends vmgenid to introduce a 32 bits generation counter > whose purpose is to be used as a VM restore notification mechanism for > the guest user-space. > > It is true that such a counter could be implemented entirely by the > guest kernel, but this would rely on the vmgenid ACPI notification to > trigger the counter update, which is inherently racy. Exposing this > through the monitor allows the updated value to be in-place before > resuming the vcpus, so interested user-space code can (atomically) > observe the update without relying on the ACPI notification.
Producing another 4 bytes is not really the issue, the issue is how does guest consume this. So I would like this discussion to happen on the linux kernel mailing list not just here. Can you post the linux patch please? > Babis Chalios (2): > vmgenid: make device data size configurable > vmgenid: add generation counter > > docs/specs/vmgenid.txt | 101 ++++++++++++++++++-------- > hw/acpi/vmgenid.c | 145 +++++++++++++++++++++++++++++++------- > include/hw/acpi/vmgenid.h | 23 ++++-- > 3 files changed, 204 insertions(+), 65 deletions(-) > > -- > 2.37.1 > > Amazon Spain Services sociedad limitada unipersonal, Calle Ramirez de Prado > 5, 28045 Madrid. Registro Mercantil de Madrid . Tomo 22458 . Folio 102 . Hoja > M-401234 . CIF B84570936