On Fri, Oct 2, 2015 at 12:25 PM, Christopher Covington <c...@codeaurora.org> wrote: > On 10/02/2015 01:25 PM, Peter Crosthwaite wrote: >> On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> On 2 October 2015 at 17:44, Christopher Covington <c...@codeaurora.org> >>> wrote: >>>> I've sent out the CPI test case and while exercising it I noticed that >>>> Laurent's patch fixed -icount. So my original goal has been accomplished. >>>> I'm >>>> happy to rebase this patch if the authorities (Peter Maydell?) think using >>>> cpu_get_ticks() is the right thing to do. Otherwise I'll probably try to >>>> move >>>> on to support for the instructions event in the ARM PMU. >>> >>> Authority here is probably Peter Crosthwaite. I can produce an >>> opinion but I'd have to go and research a bunch of stuff to do >>> that, so I'm hoping to avoid it... >> >> So my idea here is the CPU input frequency should be a property of the CPU. >> >> Some experimental results confirm that the PMCCNTR on many common ARM >> implementations is directly connected to the input clock and can be >> relied on as a straight free-running counter. I think a genuine >> instruction counter is something else > > Yes, the "genuine" instruction counter is something else. The instruction > count is only relevant for folks trying to get deterministic execution by > using the -icount option. QEMU TCG mode does not emulate a cycle-level input > clock for the guest (the whole class of functional models skip this > time-consuming step) but rather operates a block at a time. By doing a little > extra, I think it also interpolates the exact instruction count. Specifying a > fixed IPC = n is the most sensible way of deterministically calculating a > PMCCNTR_EL0 value that I know of. The -icount option allows users to choose > such deterministic behavior. > >> and this timer should be independent of any core provider of cycle count. > > What, if anything, do you think should be hooked up to the core provider of > cycle count? >
Depends, Is this a virtual-machine only concept, or do you have something with a real-hardware analogue? Regards, Peter > Christopher Covington > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project