[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure
From: |
Christopher Covington |
Subject: |
Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure |
Date: |
Fri, 02 Oct 2015 12:44:34 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 |
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
>> <address@hidden> 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 Covington <address@hidden>
>>> ---
>>> target-arm/helper.c | 9 +++------
>>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/target-arm/helper.c b/target-arm/helper.c
>>> index 7dc49cb..32923fb 100644
>>> --- a/target-arm/helper.c
>>> +++ b/target-arm/helper.c
>>> @@ -729,8 +729,7 @@ void pmccntr_sync(CPUARMState *env)
>>> {
>>> uint64_t temp_ticks;
>>>
>>> - temp_ticks = muldiv64(qemu_clock_get_us(QEMU_CLOCK_VIRTUAL),
>>> - get_ticks_per_sec(), 1000000);
>>> + temp_ticks = cpu_get_ticks();
>
>> Also I don't think this is correct. cpu_get_ticks() returns the host
>> CPU cycle counter, when in this case we want the guest cycles.
>
> I too find the use of host CPU cycles quite perplexing. Paolo suggested it
> [1]. Maybe there are timeouts in some software that tend to work better in
> such a mode. Perhaps it is faster, although my intuition is that it's just
> providing a facade of frequency scaling to the guest.
>
> 1. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00162.html
>
> I like to declare guest instructions per guest CPU cycles = 1. As I understand
> it, an "-icount 0" pair of parameters is how to do this in QEMU for x86. I'd
> like it to work for ARM.
>
> I wrote a simple assembly test case which I'm working on porting it to the
> kvm-unit-tests framework. In the non-icount case, I saw roughly the same order
> of magnitude for guest IPC before and after the patch. I'd like to also write
> CPU frequency (guest CPU cycles per generic timer guest seconds) and (M)IPS
> (guest instructions per generic timer guest seconds) tests.
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.
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
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Christopher Covington, 2015/10/07
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure,
Christopher Covington <=
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Peter Maydell, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Christopher Covington, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Peter Crosthwaite, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Christopher Covington, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Peter Maydell, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Paolo Bonzini, 2015/10/08
- Re: [Qemu-devel] [PATCH] target-arm: Use common CPU cycle infrastructure, Peter Maydell, 2015/10/08