On Sat, 27 Apr 2013 17:49:31 +0530, Anup Patel <anup@xxxxxxxxxxxxxx>
wrote:
> On Sat, Apr 27, 2013 at 2:49 PM, Marc Zyngier <marc.zyngier@xxxxxxx>
wrote:
>> On Sat, 27 Apr 2013 13:38:06 +0530, Anup Patel <anup.patel@xxxxxxxxxx>
>> wrote:
>>> The arch_timer irq numbers (or PPI numbers) are implementation
dependent
>>> so, the host virtual timer irq number can be different from guest
>> virtual
>>> timer irq number.
>>>
>>> This patch ensures that host virtual timer irq number is read from DTB
>> and
>>> guest virtual timer irq is determined based on vcpu target type.
[...]
>>>
>>> +int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> + const struct kvm_irq_level *irq)
>>> +{
>>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>> +
>>> + /*
>>> + * The vcpu timer irq number cannot be determined in
>>> + * kvm_timer_vcpu_init() because it is called much before
>>> + * kvm_vcpu_set_target(). To handle this, we determine
>>> + * vcpu timer irq number when the vcpu is resetted.
>>> + */
>>> + timer->irq = irq;
>>> +
>>> + /*
>>> + * Make sure timer is disarmed.
>>> + */
>>> + timer_disarm(timer);
>>
>> What is that for? Timer has not been started yet, for the lack of an
IRQ.
>> Actually, the vcpu has never ran. Why would you need to disarm it?
>
> This is in case a vcpu is resetted at runtime from user space or psci.
> Also, since we have named it timer_vcpu_reset(), it made sense to
> atleast disarm the timer.
I would agree if the timer had a clearly defined reset state. The ARM ARM
says that the timer register reset values are UNKNOWN. So at CPU reset, the
timer is allowed to be in any possible state, including having a pending
interrupt.
This means the guest already has to deal with the situation, and I'd
rather not give additional guarantees. Please remove this call from your
next version of this patch.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
