Re: [Xen-devel] [PATCH 1/3] arm_arch_timer: introduce arch_timer_stolen_ticks

[Christopher Covington <cov@xxxxxxxxxxxxxx>]

On 05/05/2013 12:47 PM, Stefano Stabellini wrote:
> On Fri, 3 May 2013, Marc Zyngier wrote:
>> On 03/05/13 11:43, Stefano Stabellini wrote:
>>> On Thu, 2 May 2013, Christopher Covington wrote:
>>>>> So the virtual timer should appear to have been running even while time
>>>>> is being stolen and therefore stolen time needs to be accounted via some
>>>>> other means.
>>>>
>>>> Something that's not currently obvious to me is that given that the stolen
>>>> cycle accounting should be done, what makes the architected timer interrupt
>>>> handler the ideal place to do it?
>>>
>>> That is a good question and I would appreciate suggestions to improve
>>> the patch.
>>>
>>> Given that Xen x86 and ia64 does stolen time accounting from the timer
>>> interrupt handler:
>>>
>>> arch/x86/xen/time.c:xen_timer_interrupt
>>> arch/ia64/kernel/time.c:timer_interrupt
>>>
>>> and given that the arch_timer is the only timer used by Xen on ARM and
>>> that it includes a virt_timer that is made on purpose to be used by
>>> virtual machines, I thought that it might be a good place for it.
>>>
>>> I also thought that doing it this way, KVM should be able to reuse the
>>> same hook.
>>
>> Indeed. I just need to understand how time stealing works there ;-).
>>
>> Now, KVM is not necessarily limited to arch_timers, and we've run KVM
>> using a QEMU-provided timer in the past. Can you think of a more generic
>> location for this hook? Possibly something that would satisfy the
>> requirements of other architectures while we're at it?
> 
> Probably the best option would be to reuse
> 
> kernel/sched/cputime.c:steal_account_process_tick
> 
> but that also means introducing CONFIG_PARAVIRT on arm.
> I am up for that, what do you think?

That sounds like a good move to me.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel