Hi Paolo, On 28 April 2014 13:01, Paolo Bonzini <[email protected]> wrote: > Il 25/04/2014 17:19, James Hogan ha scritto: > >> Expose the KVM guest CP0_Count bias (from the monotonic kernel time) to >> userland in nanosecond units via a new KVM_REG_MIPS_COUNT_BIAS register >> accessible with the KVM_{GET,SET}_ONE_REG ioctls. This gives userland >> control of the bias so that it can exactly match its own monotonic time. >> >> The nanosecond bias is stored separately from the raw bias used >> internally (since nanoseconds isn't a convenient or efficient unit for >> various timer calculations), and is recalculated each time the raw count >> bias is altered. The raw count bias used in CP0_Count determination is >> recalculated when the nanosecond bias is altered via the KVM_SET_ONE_REG >> ioctl. >> >> Signed-off-by: James Hogan <[email protected]> >> Cc: Paolo Bonzini <[email protected]> >> Cc: Gleb Natapov <[email protected]> >> Cc: [email protected] >> Cc: Ralf Baechle <[email protected]> >> Cc: [email protected] >> Cc: David Daney <[email protected]> >> Cc: Sanjay Lal <[email protected]> > > > If it is possible and not too hairy to use a raw value in userspace > (together with KVM_REG_MIPS_COUNT_HZ), please do it---my suggestions were > just that, a suggestion. Otherwise, the patch looks good.
Do you mean expose the raw internal offset to userland instead of the nanosecond one? Yeh it should be possible & slightly simpler for both kernel and Qemu actually. Qemu could then store that value (or the Count register) straight into env->CP0_Count (depending on Cause.DC), then hw/mips/cputimer.c would pretty much continue to work accurately. cputimer.c is only really made use of by tcg at the moment though (reading/writing count/compare/cause.DC), but it still makes sense to be consistent. Cheers James -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
