From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: HVM Migration of domU on Qemu-upstream DM causes stuck system clock with ACPI Date: Mon, 3 Jun 2013 18:25:37 +0100 Message-ID: <51ACD191.1080808@eu.citrix.com> References: <1717491994.10371605.1369131737226.JavaMail.root@zimbra002> <420439EA40B15FCBFDFF2BE3@nimrod.local> <1369557503.22605.11.camel@dagon.hellion.org.uk> <51A4C7EB.1010406@flexiant.com> <51A7767A.9030904@flexiant.com> <51A7791C.2020208@eu.citrix.com> <51A8608F.9000302@flexiant.com> <51A88151.3080001@eu.citrix.com> <0FE70400-1152-45F5-9BF9-973DF1DA9EE8@flexiant.com> <51A88E3E.5090208@eu.citrix.com> <1370004031.5199.133.camel@zakaz.uk.xensource.com> <51A8A0AC.1030301@eu.citrix.com> <51A8BD48.6060104@citrix.com> <51AC55DD.7000507@citrix.com> <51AC6EB6.2010108@citrix.com> <51AC7B1D.8020308@eu.citrix.com> <51ACCE8F.9010703@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Alex Bligh Cc: Ian Campbell , Stefano Stabellini , Konrad Rzeszutek Wilk , xen-devel@lists.xen.org, David Vrabel , Anthony PERARD , Diana Crisan , =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= List-Id: xen-devel@lists.xenproject.org On 03/06/13 18:18, Alex Bligh wrote: > George, > > --On 3 June 2013 18:12:47 +0100 George Dunlap > wrote: > >>> Will this work with all guests? We (unfortunately) do not know whether >>> the >>> guest is Linux with or without PV, Windows with or without PV or >>> what. I >>> /think/ this is going to give problems when the guest is not using >>> the PV timer (including Windows). Is that right? >>> >>> I'd be happiest if it selected native_paravirt whenever the guest was >>> using the PV timer, but not otherwise. Happy to test patches for that. >> >> I'm not sure the effect, but I suspect it probably won't work quite >> right. Might be worth a quick test. >> >> We do want to fix this properly (which means, "just works w/o having to >> use a work-around"); I'm trying to understand the exact nature of the >> error now. > > Sorry did you mean using native_paravirt on Linux guests with PV support > wouldn't work quite right, or using that on all guests wouldn't work > quite > right, or that switching automatically if use of the PV timer was > detected wouldn't work quite right? I mean that if you enable it for guests that aren't using a PV clocksource (e.g., Windows guests), I'm not sure what will happen. It might be fine, but you should probably test it. :-) Switching TSC modes isn't the right thing to do -- the right thing is to figure out where the math is getting messed up and make it work properly no matter which mode you're in. -George