qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure
Date: Fri, 2 Oct 2015 12:56:37 -0700

On Fri, Oct 2, 2015 at 12:25 PM, Christopher Covington
<address@hidden> wrote:
> On 10/02/2015 01:25 PM, Peter Crosthwaite wrote:
>> On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell <address@hidden> wrote:
>>> On 2 October 2015 at 17:44, Christopher Covington <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]