On 3/8/22 18:40, David Woodhouse wrote:
On Tue, 2022-03-08 at 18:25 +0100, Paolo Bonzini wrote:
On 3/8/22 18:20, David Woodhouse wrote:
Yes, I'm just talking about the second hunk. The first is clear(ish).
Oh, I see.
When the oneshot timer has expired and hasn't been re-armed by the
guest, we should return zero as 'expires_ns' so that it doesn't get re-
armed in the past (and, hopefully, immediately retriggered) when the
guest is restored.
Also, we don't really want the timer firing*after* the guest vCPU
state has been serialized, since the newly-injected interrupt might not
get migrated. Hence using hrtimer_cancel() as our check for whether
it's still pending or not.
Sure. But if we consider it acceptable for the timer to fire again
after live migration when it already fired on the source host why did
we even bother fixing the first part above? :)
In the first case the timer has expired and the event has been injected
by the time the state is retrieved, so you'd get a double event.
In the second the timer expires and the event is injected _on the
source_ only. This is required because, if the destination for
whatever reason aborts the migration, your change would introduced a
missed event.
Paolo
