Hi Paolo,
On 28 April 2014 13:01, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 <james.hogan@xxxxxxxxxx>
>> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
>> Cc: Gleb Natapov <gleb@xxxxxxxxxx>
>> Cc: kvm@xxxxxxxxxxxxxxx
>> Cc: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
>> Cc: linux-mips@xxxxxxxxxxxxxx
>> Cc: David Daney <david.daney@xxxxxxxxxx>
>> Cc: Sanjay Lal <sanjayl@xxxxxxxxxxx>
>
>
> 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
