Messages in this thread | | | From | Christophe de Dinechin <> | Subject | Re: [PATCH 1/9] KVM: arm64: Document PV-time interface | Date | Mon, 05 Aug 2019 18:40:54 +0200 |
| |
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)
| |