From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Guthro Subject: Re: XSAVE/XRSTOR crash resurgence in 4.3 Date: Mon, 15 Jul 2013 09:49:15 -0400 Message-ID: References: <51D592E502000078000E2C7D@nat28.tlf.novell.com> <930123250021152322@unknownmsgid> <51D6BC5E02000078000E2F24@nat28.tlf.novell.com> <-6045434008888857231@unknownmsgid> <51D6D4F902000078000E2FB4@nat28.tlf.novell.com> <-3560575408827160717@unknownmsgid> <51DAE7D002000078000E3583@nat28.tlf.novell.com> <51DAEB9602000078000E3596@nat28.tlf.novell.com> <1344752101264964129@unknownmsgid> <51DAED2302000078000E35A6@nat28.tlf.novell.com> <51E0230702000078000E47DE@nat28.tlf.novell.com> <51E02FF802000078000E4882@nat28.tlf.novell.com> <51E034E502000078000E48D2@nat28.tlf.novell.com> <51E4084602000078000E4FBB@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Jan Beulich Cc: Mark Roddy , xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, Jul 15, 2013 at 8:43 AM, Ben Guthro wrote: > On Mon, Jul 15, 2013 at 8:33 AM, Jan Beulich wrote: >>>>> On 12.07.13 at 17:14, Ben Guthro wrote: >>> On other systems, with this same build, I see the debug output in the logs. >>> >>> However, it is absent on this system >> >> Just looked over the debugging patch again, and can't see what >> might be wrong with it. Following what you say there must be >> something different between the hosts and/or guests between >> those systems. >> >> Are you, on the other systems, perhaps only ever seeing the >> message added to xrstor(), which would also get printed for >> 64-bit HVM guests? > > Hmm... this may very well be possible. > I certainly see the messages on 64bit guests. > > I need to collect some more data to understand where, and when I'm > seeing the problem. > Trying to form a theory around a limited data set is challenging here. Well...there goes that theory The following output was from a WinXP SP3 guest (32bit) on a Lenovo T430: (XEN) d1v0: fip=1b773d6e9a fdp=23773d1c48 w=8 (XEN) d1v0: FIP=1b773d6e9a FDP=23773d1c48 w=8 (XEN) d1v1: fip=1b79e78dee fdp=230012e3b4 w=8 (XEN) d1v1: FIP=1b79e78dee FDP=230012e3b4 w=8 (XEN) d1v1: fip=0000:79e78dee fdp=0000:0012e3b4 (XEN) d1v1: fip=0000:79e78dee fdp=0000:0012e3b4 (XEN) d1v1: fip=0000:79e78dee fdp=0000:0012e3b4 (XEN) d1v1: fip=0000:79e78dee fdp=0000:0012e3b4 (XEN) d1v1: fip=1b79e78dee fdp=230012d528 w=8 (XEN) d1v1: FIP=1b79e78dee FDP=230012d528 w=8 (XEN) d1v0: fip=4500000000 fdp=4b1000000000 w=8 (XEN) d1v0: FIP=4500000000 FDP=4b1000000000 w=8 (XEN) d1v1: fip=1b773d6e9a fdp=23773d1c48 w=8 (XEN) d1v1: FIP=1b773d6e9a FDP=23773d1c48 w=8 I have some more logs to go through. I'll reply again if I find anything worth noting. > >> If so, we may need to add another printk() >> to the other case within that switch statement (albeit getting >> there would seem to imply that on the matching xsave() run >> the selectors would still have been non-null, or else one of the >> printk()s should have got executed)... >> >> And I take it, btw, that there's no migration or save/restore >> involved here? >> >> Jan >>