On 10/13/2015 04:53 PM, Peter Maydell wrote:
> On 24 September 2015 at 20:43, Christopher Covington
> wrote:
>> cpu_get_ticks() provides a common interface across targets for
>> calculating CPU cycles. Using this fixes PMCCNTR reads when -icount
>> is specified (previously a non-increasing value
On 24 September 2015 at 20:43, Christopher Covington
wrote:
> cpu_get_ticks() provides a common interface across targets for
> calculating CPU cycles. Using this fixes PMCCNTR reads when -icount
> is specified (previously a non-increasing value was returned).
>
> Signed-off-by: Christopher Coving
On 06/10/2015 15:06, Peter Maydell wrote:
> Looking closer, clock_gettime() also has a userspace
> only fastpath in the VDSO.
Yup, hence the patch that changed the default cpu_get_real_ticks()
implementation to get_clock().
>> > Could we just use CNTVCT_EL0? Which cores have it?
>
> Not guaran
On 6 October 2015 at 13:58, Paolo Bonzini wrote:
>
>
> On 06/10/2015 14:49, Peter Maydell wrote:
>> Yeah, there's no guarantee on userspace access. I think the
>> fastest way to get some kind of count is to use a library
>> function that boils down to gettimeofday(2), which we will
>> do purely in
On 06/10/2015 14:49, Peter Maydell wrote:
> Yeah, there's no guarantee on userspace access. I think the
> fastest way to get some kind of count is to use a library
> function that boils down to gettimeofday(2), which we will
> do purely in userspace in the kernel VDSO if possible.
Could we just
On 5 October 2015 at 15:27, Paolo Bonzini wrote:
> I remember seeing a bug where this terrible implementation caused
> divisions by zero on the host. The default implementation in
> include/qemu/timer.h should be changed to
> qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL).
>
> Note that in practice this t
On 05/10/2015 16:11, Peter Maydell wrote:
> > > OTOH various non-x86 things do use the closely related
> > > cpu_get_real_ticks(),
> > > and the implementation of cpu_get_ticks() is very closely related to
> > > the other clock code in cpus.c.
> >
> > cpu_get_real_ticks() is returning the host c
On 5 October 2015 at 15:09, Paolo Bonzini wrote:
>
>
> On 03/10/2015 00:41, Peter Maydell wrote:
>> > 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.
>>
>> OTOH var
On 03/10/2015 00:41, Peter Maydell wrote:
> > 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.
>
> OTOH various non-x86 things do use the closely related cpu_get_real_ticks
On 2 October 2015 at 21:48, Christopher Covington wrote:
> 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.
OTOH various non-x86 things do use the closely related cpu_get_real_
On 10/02/2015 03:56 PM, Peter Crosthwaite wrote:
> On Fri, Oct 2, 2015 at 12:25 PM, Christopher Covington
> wrote:
>> On 10/02/2015 01:25 PM, Peter Crosthwaite wrote:
>>> On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell
>>> wrote:
On 2 October 2015 at 17:44, Christopher Covington
wrote:
On Fri, Oct 2, 2015 at 12:25 PM, Christopher Covington
wrote:
> On 10/02/2015 01:25 PM, Peter Crosthwaite wrote:
>> On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell
>> wrote:
>>> On 2 October 2015 at 17:44, Christopher Covington
>>> wrote:
I've sent out the CPI test case and while exercising
On 10/02/2015 01:25 PM, Peter Crosthwaite wrote:
> On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell
> wrote:
>> On 2 October 2015 at 17:44, Christopher Covington
>> wrote:
>>> I've sent out the CPI test case and while exercising it I noticed that
>>> Laurent's patch fixed -icount. So my original g
On Fri, Oct 2, 2015 at 11:08 AM, Peter Maydell wrote:
> On 2 October 2015 at 18:25, Peter Crosthwaite
> wrote:
>> 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
On 2 October 2015 at 18:25, Peter Crosthwaite
wrote:
> 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 straig
On Fri, Oct 2, 2015 at 9:56 AM, Peter Maydell wrote:
> On 2 October 2015 at 17:44, Christopher Covington 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
On 2 October 2015 at 17:44, Christopher Covington 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_t
On 09/29/2015 10:07 AM, Christopher Covington wrote:
> On 09/28/2015 06:05 PM, Alistair Francis wrote:
>> On Thu, Sep 24, 2015 at 12:43 PM, Christopher Covington
>> wrote:
>>> cpu_get_ticks() provides a common interface across targets for
>>> calculating CPU cycles. Using this fixes PMCCNTR reads
On 09/28/2015 06:05 PM, Alistair Francis wrote:
> On Thu, Sep 24, 2015 at 12:43 PM, Christopher Covington
> wrote:
>> cpu_get_ticks() provides a common interface across targets for
>> calculating CPU cycles. Using this fixes PMCCNTR reads when -icount
>> is specified (previously a non-increasing v
On Thu, Sep 24, 2015 at 12:43 PM, Christopher Covington
wrote:
> cpu_get_ticks() provides a common interface across targets for
> calculating CPU cycles. Using this fixes PMCCNTR reads when -icount
> is specified (previously a non-increasing value was returned).
>
> Signed-off-by: Christopher Covi
cpu_get_ticks() provides a common interface across targets for
calculating CPU cycles. Using this fixes PMCCNTR reads when -icount
is specified (previously a non-increasing value was returned).
Signed-off-by: Christopher Covington
---
target-arm/helper.c | 9 +++--
1 file changed, 3 insertio
21 matches
Mail list logo
