On Mon, Aug 16, 2021 at 12:12:13AM +0000, Oliver Upton wrote: > Allow userspace to access the guest's virtual counter-timer offset > through the ONE_REG interface. The value read or written is defined to > be an offset from the guest's physical counter-timer. Add some > documentation to clarify how a VMM should use this and the existing > CNTVCT_EL0. > > Signed-off-by: Oliver Upton <oupton@xxxxxxxxxx> > Reviewed-by: Andrew Jones <drjones@xxxxxxxxxx> Hrm... I was mulling on this patch a bit more and had a thought. As previously discussed, the patch implements virtual offsets by broadcasting the same offset to all vCPUs in a guest. I wonder if this may tolerate bad practices from userspace that will break when KVM supports NV. Consider that a nested guest may set CNTVOFF_EL2 to whatever value it wants. Presumably, we will need to patch the handling of CNTVOFF_EL2 to *not* broadcast to all vCPUs to save/restore NV properly. If a maligned VMM only wrote to a single vCPU, banking on this broadcasting implementation, it will fall flat on its face when handling an NV guest. So, should we preemptively move to the new way of the world, wherein userspace accesses to CNTVOFF_EL2 are vCPU-local rather than VM-wide? No strong opinions in either direction, but figured I'd address it since I'll need to respin this series anyway to fix ECV+nVHE. -- Thanks, Oliver
