From: Paul Durrant <pdurrant@xxxxxxxxxx> This series is based on my v9 of my "update shared_info and vcpu_info handling" series [1] and fixes an issue that was latent before the "allow shared_info to be mapped by fixed HVA" patch of that series allowed a VMM to set up shared_info before the VM booted and then leave it alone. The problem was noticed when the guest wallclock apparently reverted to the Unix epoch. This was because, when the shared_info was set up the guest's long_mode flag was unset and hence the wallclock was intialized in the place where a 32-bit guest would expect to find it. The 64-bit guest being tested instead found zero-ed out memory. Fix the the issue by first separating the initialization of the shared_info content from setting its location (by HVA or GPA) and then (re-)initializing the content any time the long_mode flag is changed. [1] https://lore.kernel.org/kvm/20231122121822.1042-1-paul@xxxxxxx/ Paul Durrant (2): KVM: xen: separate initialization of shared_info cache and content KVM: xen: (re-)initialize shared_info if guest (32/64-bit) mode is set arch/x86/kvm/xen.c | 84 ++++++++++++++++++++++++++++------------------ 1 file changed, 52 insertions(+), 32 deletions(-) base-commit: 369e9826edfd346f259471e521c03e12bb0ab476 -- 2.39.2
