On 10/02/2015 03:56 PM, Peter Crosthwaite wrote: > 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?
What I meant to ask was, do you see any reason for cpu_get_ticks() to exist? If no architecture besides i386 wants to use it, perhaps the code should be moved there. Thanks, Christopher Covington -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
