From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 14/21] MIPS: KVM: Add nanosecond count bias KVM register Date: Mon, 28 Apr 2014 17:42:49 +0200 Message-ID: <535E76F9.7050001@redhat.com> References: <1398439204-26171-1-git-send-email-james.hogan@imgtec.com> <1398439204-26171-15-git-send-email-james.hogan@imgtec.com> <535E4310.10308@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org, Ralf Baechle , Linux MIPS Mailing List , David Daney , Sanjay Lal To: James Hogan Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38671 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756658AbaD1PnG (ORCPT ); Mon, 28 Apr 2014 11:43:06 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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