Steven Price writes: > Introduce a paravirtualization interface for KVM/arm64 based on the > "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A. > > This only adds the details about "Stolen Time" as the details of "Live > Physical Time" have not been fully agreed. > [...] > + > +Stolen Time > +----------- > + > +The structure pointed to by the PV_TIME_ST hypercall is as follows: > + > + Field | Byte Length | Byte Offset | Description > + ----------- | ----------- | ----------- | -------------------------- > + Revision | 4 | 0 | Must be 0 for version 0.1 > + Attributes | 4 | 4 | Must be 0 > + Stolen time | 8 | 8 | Stolen time in unsigned > + | | | nanoseconds indicating how > + | | | much time this VCPU thread > + | | | was involuntarily not > + | | | running on a physical CPU. I know very little about the topic, but I don't understand how the spec as proposed allows an accurate reading of the relation between physical time and stolen time simultaneously. In other words, could you draw Figure 1 of the spec from within the guest? Or is it a non-objective? For example, if you read the stolen time before you read CNTVCT_EL0, isn't it possible for a lengthy event like a migration to occur between the two reads, causing the stolen time to be obsolete and off by seconds? -- Cheers, Christophe de Dinechin (IRC c3d) _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
