On Mon, 2023-10-02 at 10:00 -0700, Sean Christopherson wrote: > > > case KVM_XEN_VCPU_ATTR_TYPE_TIMER: > > + /* > > + * Ensure a consistent snapshot of state is captured, with a > > + * timer either being pending, or the event channel delivered > > + * to the corresponding bit in the shared_info. Not still > > + * lurking in the timer_pending flag for deferred delivery. > > + * Purely as an optimisation, if the timer_expires field is > > + * zero, that means the timer isn't active (or even in the > > + * timer_pending flag) and there is no need to cancel it. > > + */ > > Ah, kvm_xen_start_timer() zeros timer_pending. > > Given that, shouldn't it be impossible for xen_timer_callback() to observe a > non-zero timer_pending value? E.g. couldn't this code WARN? > > if (atomic_read(&vcpu->arch.xen.timer_pending)) > return HRTIMER_NORESTART; > > Obviously not a blocker for this patch, I'm mostly just curious to know if I'm > missing something. Yes, I believe that is true.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
