Re: XSAVE/XRSTOR crash resurgence in 4.3

[Ben Guthro <ben.guthro@gmail.com>]

On Mon, Jul 15, 2013 at 8:43 AM, Ben Guthro <ben.guthro@gmail.com> wrote:
> On Mon, Jul 15, 2013 at 8:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 12.07.13 at 17:14, Ben Guthro <ben.guthro@gmail.com> 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
>>