Il 28/04/2014 17:17, James Hogan ha scritto:
> 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.
Yes, when I reviewed the QEMU patches I missed this consequence of
exposing the HZ.
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.
Yup. cputimer.c would just use a HZ value stored in CPUMIPSState
(TIMER_FREQ for TCG) instead of hardcoding TIMER_FREQ I guess.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
