Re: [Xen-devel] HVM Migration of domU on Qemu-upstream DM causes stuck system clock with ACPI

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 31 May 2013 12:49:18 +0100 George Dunlap <george.dunlap@xxxxxxxxxxxxx> 
wrote:
> No -- Linux is asking, "Can you give me an alarm in 5ns?"  And Xen is
> saying, "No".  So Linux is saying, "OK, how about 5us?  10us? 20us?"  By
> the time it reaches 4ms, Linux has had enough, and says, "If this timer
> is so bad that it can't give me an event within 4ms it just won't use
> timers at all, thank you very much."
>
> The problem appears to be that Linux thinks it's asking for something in
> the future, but is actually asking for something in the past.  It must
> look at its watch just before the final domain pause, and then asks for
> the time just after the migration resumes on the other side.  So it
> doesn't realize that 10ms (or something) has already passed, and that
> it's actually asking for a timer in the past.  The Xen timer driver in
> Linux specifically asks Xen for times set in the past to return an error.
> Xen is returning an error because the time is in the past, Linux thinks
> it's getting an error because the time is too close in the future and
> tries asking a little further away.
>
> Unfortunately I think this is something which needs to be fixed on the
> Linux side; I don't really see how we can work around it in Xen.
I don't think fixing it only on the Linux side is a great idea, not least 
as it makes any current Linux image not live migrateable reliably. That's 
pretty horrible.
What would happen if Xen simply lied, then delivered the event a bit late? 
(obviously post migrate only). Obviously this would mean events wouldn't be 
delivered at exactly the right time, but in most circumstances that would 
be better than the guest wallclock simply dying.
--
Alex Bligh

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