Message ID | 56A8E20C02000078000CB944@prv-mh.provo.novell.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Latest set looks good. No boot issues. No resets. Full log at http://paste2.org/NxHNW4vn Sorry I don't know much about source of last few lines. I was just tracing in xen when these came. I was unable to create them again. I will inform you if I get these again. Regards, Harmandeep On Wed, Jan 27, 2016 at 7:58 PM, Jan Beulich <JBeulich@suse.com> wrote: >>>> On 27.01.16 at 14:28, <write.harmandeep@gmail.com> wrote: >> I tried to apply your patches but it seems >> to have some merge conflicts with latest >> staging branch. >> >> ~/xen$ git apply ~/Downloads/x86-xsaves-init.patch >> error: patch failed: xen/arch/x86/hvm/hvm.c:2094 >> error: xen/arch/x86/hvm/hvm.c: patch does not apply > > Oh, indeed. Here's a better set. > > Jan >
>>> On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote: > Latest set looks good. No boot issues. No resets. > Full log at http://paste2.org/NxHNW4vn Thanks! > Sorry I don't know much about source of last few > lines. I was just tracing in xen when these came. > I was unable to create them again. I will inform > you if I get these again. The WRMSR ones are of no concern. What I'm curious about are the five instances of (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15 Could you check what these addresses correspond to in source? Also did you meanwhile clarify for yourself what domain(s) are being started here? So far you've said you don't start any, but the logs clearly show otherwise. Are there perhaps any that get auto-started? In which case I'd be interested in you confirming that these come up fine. Jan
Hey Harmandeep, On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote: > > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote: > > Latest set looks good. No boot issues. No resets. > > Full log at http://paste2.org/NxHNW4vn > > > Sorry I don't know much about source of last few > > lines. I was just tracing in xen when these came. > > I was unable to create them again. I will inform > > you if I get these again. > > The WRMSR ones are of no concern. What I'm curious about are the > five instances of > > (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15 > > Could you check what these addresses correspond to in source? > I guess you just happened to forgot to follow up on this question from Jan? > So far you've said you don't start any, but > the logs clearly show otherwise. Are there perhaps any that > get auto-started? In which case I'd be interested in you > confirming that these come up fine. > And this too? Can you please do that? :-) Regards, Dario
On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli <dario.faggioli@citrix.com> wrote: > Hey Harmandeep, > > On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote: >> > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote: >> > Latest set looks good. No boot issues. No resets. >> > Full log at http://paste2.org/NxHNW4vn >> >> > Sorry I don't know much about source of last few >> > lines. I was just tracing in xen when these came. >> > I was unable to create them again. I will inform >> > you if I get these again. >> >> The WRMSR ones are of no concern. What I'm curious about are the >> five instances of >> >> (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15 >> >> Could you check what these addresses correspond to in source? >> > I guess you just happened to forgot to follow up on this question from > Jan? Sorry for responding so late. $ addr2line -e xen-syms ffff82d08019cb87 xen/xen/arch/x86/traps.c:2820 >> So far you've said you don't start any, but >> the logs clearly show otherwise. Are there perhaps any that >> get auto-started? In which case I'd be interested in you >> confirming that these come up fine. >> Maybe I failed to shutdown a guest which was showing up on next boot. But there are no auto-starting guests. Following link goes to latest serial log http://paste2.org/5PDz9bP1 and then I created a guest with config (http://paste2.org/azvj25Hg) and http://paste2.org/cgKna0j1 log was presented at terminal. I hope this helps. Thanks and regards, Harmandeep Kaur > And this too? > > Can you please do that? :-) > > Regards, > Dario > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) >
>>> On 03.02.16 at 12:35, <write.harmandeep@gmail.com> wrote: > On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli > <dario.faggioli@citrix.com> wrote: >> Hey Harmandeep, >> >> On Fri, 2016-01-29 at 03:13 -0700, Jan Beulich wrote: >>> > > > On 28.01.16 at 20:17, <write.harmandeep@gmail.com> wrote: >>> > Latest set looks good. No boot issues. No resets. >>> > Full log at http://paste2.org/NxHNW4vn >>> >>> > Sorry I don't know much about source of last few >>> > lines. I was just tracing in xen when these came. >>> > I was unable to create them again. I will inform >>> > you if I get these again. >>> >>> The WRMSR ones are of no concern. What I'm curious about are the >>> five instances of >>> >>> (XEN) traps.c:3290: GPF (0000): ffff82d08019cb87 -> ffff82d080242e15 >>> >>> Could you check what these addresses correspond to in source? >>> >> I guess you just happened to forgot to follow up on this question from >> Jan? > > Sorry for responding so late. Thanks for getting back. > $ addr2line -e xen-syms ffff82d08019cb87 > xen/xen/arch/x86/traps.c:2820 That's the RDMSR one, so (luckily) not of interest here. >>> So far you've said you don't start any, but >>> the logs clearly show otherwise. Are there perhaps any that >>> get auto-started? In which case I'd be interested in you >>> confirming that these come up fine. >>> > > Maybe I failed to shutdown a guest which was showing up > on next boot. But there are no auto-starting guests. > Following link goes to latest serial log > http://paste2.org/5PDz9bP1 and then I created a guest with But this _again_ shows the presence of a (running) Dom1, ... > config (http://paste2.org/azvj25Hg) and > http://paste2.org/cgKna0j1 log was presented at terminal. ... and you leave us guessing whether the first of these logs was indeed captured before you started the guest (as one may imply from your wording) or after (as one may imply from your claim of there not being any auto-started guests). Please try to be more precise in your statements. Jan
On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote: > On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli > <dario.faggioli@citrix.com> wrote: > > > Maybe I failed to shutdown a guest which was showing up > on next boot. But there are no auto-starting guests. > Following link goes to latest serial log > http://paste2.org/5PDz9bP1 > No, sorry, I probably am not getting. Are you saying that, just booting Xen and *not* doing anything else --either from SSH, from the keyboard of that box, from serial connection... anything at all-- and without any guest configured to auto start itself, results in these lines to appear on your serial console? tbox login: (d1) mapping kernel into physical memory (d1) about to get started... (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. Because this is what you just said above, and that's... well... just impossible?!?! :-O What's the output then, if you login (either via serial, ssh or regular keyboad+monitor) and run `xl list' and `xl vcpu-list' as the very first thing? What's inside `ls -l /var/log/xen/' (or `ls -l /var/local/log/xen')? > and then I created a guest with > config (http://paste2.org/azvj25Hg) and > http://paste2.org/cgKna0j1 log was presented at terminal. > Well, it looks like the guest boot did not indeed go well, but that is probably because of other thing... can you try uncommenting the line 'extra = "root=/dev/xvda1"' from the config? Regards, Dario
On 03/02/16 12:55, Dario Faggioli wrote: > On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote: >> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli >> <dario.faggioli@citrix.com> wrote: >>> >> Maybe I failed to shutdown a guest which was showing up >> on next boot. But there are no auto-starting guests. >> Following link goes to latest serial log >> http://paste2.org/5PDz9bP1 >> > No, sorry, I probably am not getting. Are you saying that, just booting > Xen and *not* doing anything else --either from SSH, from the keyboard > of that box, from serial connection... anything at all-- and without > any guest configured to auto start itself, results in these lines to > appear on your serial console? > > tbox login: (d1) mapping kernel into physical memory > (d1) about to get started... > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. > > Because this is what you just said above, and that's... well... just > impossible?!?! :-O This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it shouldn't. There is a fix upstream, but this specifically is harmless noise. ~Andrew
On Wed, 2016-02-03 at 13:10 +0000, Andrew Cooper wrote: > On 03/02/16 12:55, Dario Faggioli wrote: > > > > tbox login: (d1) mapping kernel into physical memory > > (d1) about to get started... > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 > > from 0xe023e00800000000 to 0x0023001000000000. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 > > from 0xffff82d0bfffe080 to 0xffffffff817ef990. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 > > from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 > > from 0x000000000000e008 to 0x0000000000000010. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 > > from 0xffff83026d40ffc0 to 0x0000000000000000. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 > > from 0x0000000000074700 to 0x0000000000047700. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 > > from 0xe023e00800000000 to 0x0023001000000000. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 > > from 0xffff82d0bffff000 to 0xffffffff817ef990. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 > > from 0xffff82d0bffff020 to 0xffffffff817f1f60. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 > > from 0x000000000000e008 to 0x0000000000000010. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 > > from 0xffff8300866fffc0 to 0x0000000000000000. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 > > from 0x0000000000074700 to 0x0000000000047700. > > > > Because this is what you just said above, and that's... well... > > just > > impossible?!?! :-O > > This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it > shouldn't. There is a fix upstream, but this specifically is > harmless > noise. > That's ok... What we're arguing is that is happens as a consequence of a domain being created, not just "by itself, after boot, without starting any domain" !!!! :-) Regards, Dario
On Wed, Feb 3, 2016 at 6:25 PM, Dario Faggioli <dario.faggioli@citrix.com> wrote: > On Wed, 2016-02-03 at 17:05 +0530, Harmandeep Kaur wrote: >> On Wed, Feb 3, 2016 at 1:53 PM, Dario Faggioli >> <dario.faggioli@citrix.com> wrote: >> > >> Maybe I failed to shutdown a guest which was showing up >> on next boot. But there are no auto-starting guests. >> Following link goes to latest serial log >> http://paste2.org/5PDz9bP1 >> > No, sorry, I probably am not getting. Are you saying that, just booting > Xen and *not* doing anything else --either from SSH, from the keyboard > of that box, from serial connection... anything at all-- and without > any guest configured to auto start itself, results in these lines to > appear on your serial console? > > tbox login: (d1) mapping kernel into physical memory > (d1) about to get started... > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bfffe080 to 0xffffffff817ef990. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 from 0xffff83026d40ffc0 to 0x0000000000000000. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff817ef990. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff817f1f60. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 from 0xffff8300866fffc0 to 0x0000000000000000. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. > > Because this is what you just said above, and that's... well... just > impossible?!?! :-O > > What's the output then, if you login (either via serial, ssh or regular > keyboad+monitor) and run `xl list' $ sudo xl list Name ID Mem VCPUs State Time(s) Domain-0 0 4096 4 r----- 37.6 > and `xl vcpu-list' as the very first > thing? $ sudo xl vcpu-list Name ID VCPU CPU State Time(s) Affinity (Hard / Soft) Domain-0 0 0 3 r-- 13.3 all / all Domain-0 0 1 0 -b- 7.0 all / all Domain-0 0 2 1 -b- 5.4 all / all Domain-0 0 3 2 r-- 13.5 all / all > What's inside `ls -l /var/log/xen/' (or `ls -l > /var/local/log/xen')? $ ls -l /var/log/xen/ total 48 -rw-r--r-- 1 root adm 28 Jan 23 00:14 xen-hotplug.log -rw-r--r-- 1 root adm 91 Feb 3 17:14 xl-ubuntu.pvlinux.log -rw-r--r-- 1 root adm 91 Jan 29 00:54 xl-ubuntu.pvlinux.log.1 -rw-r--r-- 1 root adm 144 Jan 26 23:50 xl-ubuntu.pvlinux.log.10 -rw-r--r-- 1 root adm 91 Jan 29 00:41 xl-ubuntu.pvlinux.log.2 -rw-r--r-- 1 root adm 91 Jan 29 00:32 xl-ubuntu.pvlinux.log.3 -rw-r--r-- 1 root adm 91 Jan 29 00:24 xl-ubuntu.pvlinux.log.4 -rw-r--r-- 1 root adm 91 Jan 28 22:22 xl-ubuntu.pvlinux.log.5 -rw-r--r-- 1 root adm 62 Jan 27 19:09 xl-ubuntu.pvlinux.log.6 -rw-r--r-- 1 root adm 91 Jan 27 19:07 xl-ubuntu.pvlinux.log.7 -rw-r--r-- 1 root adm 222 Jan 27 18:41 xl-ubuntu.pvlinux.log.8 -rw-r--r-- 1 root adm 62 Jan 27 15:03 xl-ubuntu.pvlinux.log.9 > >> and then I created a guest with >> config (http://paste2.org/azvj25Hg) and >> http://paste2.org/cgKna0j1 log was presented at terminal. >> > Well, it looks like the guest boot did not indeed go well, but that is > probably because of other thing... can you try uncommenting the line > 'extra = "root=/dev/xvda1"' from the config? Trying this suggestion. > > Regards, > Dario > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) >
>>> On 03.02.16 at 14:40, <write.harmandeep@gmail.com> wrote: > $ ls -l /var/log/xen/ > total 48 > -rw-r--r-- 1 root adm 28 Jan 23 00:14 xen-hotplug.log > -rw-r--r-- 1 root adm 91 Feb 3 17:14 xl-ubuntu.pvlinux.log This date looks suspiciously new. Jan
On Wed, Feb 03, 2016 at 02:17:26PM +0100, Dario Faggioli wrote: > On Wed, 2016-02-03 at 13:10 +0000, Andrew Cooper wrote: > > On 03/02/16 12:55, Dario Faggioli wrote: > > > > > > tbox login: (d1) mapping kernel into physical memory > > > (d1) about to get started... > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000081 > > > from 0xe023e00800000000 to 0x0023001000000000. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000082 > > > from 0xffff82d0bfffe080 to 0xffffffff817ef990. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000083 > > > from 0xffff82d0bfffe0a0 to 0xffffffff817f1f60. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000174 > > > from 0x000000000000e008 to 0x0000000000000010. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000175 > > > from 0xffff83026d40ffc0 to 0x0000000000000000. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 0000000000000176 > > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > > > (XEN) traps.c:2684:d1v0 Domain attempted WRMSR 00000000c0000084 > > > from 0x0000000000074700 to 0x0000000000047700. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000081 > > > from 0xe023e00800000000 to 0x0023001000000000. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000082 > > > from 0xffff82d0bffff000 to 0xffffffff817ef990. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000083 > > > from 0xffff82d0bffff020 to 0xffffffff817f1f60. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000174 > > > from 0x000000000000e008 to 0x0000000000000010. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000175 > > > from 0xffff8300866fffc0 to 0x0000000000000000. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 0000000000000176 > > > from 0xffff82d08023eaf0 to 0xffffffff817f1d60. > > > (XEN) traps.c:2684:d1v1 Domain attempted WRMSR 00000000c0000084 > > > from 0x0000000000074700 to 0x0000000000047700. > > > > > > Because this is what you just said above, and that's... well... > > > just > > > impossible?!?! :-O > > > > This is a Linux PV trying to set up the SYSCALL/SYSENTER MSRs when it > > shouldn't. There is a fix upstream, but this specifically is > > harmless > > noise. > > > That's ok... What we're arguing is that is happens as a consequence of > a domain being created, not just "by itself, after boot, without > starting any domain" !!!! :-) It has booted. It says 'about to get started...' which is in the early code of the Linux pvops.
--- unstable.orig/xen/arch/x86/xstate.c 2016-01-25 09:35:12.000000000 +0100 +++ unstable/xen/arch/x86/xstate.c 2016-01-27 10:23:06.000000000 +0100 @@ -29,6 +29,8 @@ unsigned int *__read_mostly xstate_sizes static unsigned int __read_mostly xstate_features; static unsigned int __read_mostly xstate_comp_offsets[sizeof(xfeature_mask)*8]; +static uint32_t __read_mostly mxcsr_mask = MXCSR_DEFAULT; + /* Cached xcr0 for fast read */ static DEFINE_PER_CPU(uint64_t, xcr0); @@ -342,6 +344,7 @@ void xrstor(struct vcpu *v, uint64_t mas uint32_t hmask = mask >> 32; uint32_t lmask = mask; struct xsave_struct *ptr = v->arch.xsave_area; + unsigned int faults, prev_faults; /* * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception @@ -361,35 +364,85 @@ void xrstor(struct vcpu *v, uint64_t mas /* * XRSTOR can fault if passed a corrupted data block. We handle this * possibility, which may occur if the block was passed to us by control - * tools or through VCPUOP_initialise, by silently clearing the block. + * tools or through VCPUOP_initialise, by silently adjusting state. */ - switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) ) + for ( prev_faults = faults = 0; ; prev_faults = faults ) { + switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) ) + { #define XRSTOR(pfx) \ alternative_io("1: .byte " pfx "0x0f,0xae,0x2f\n" \ + "3:\n" \ " .section .fixup,\"ax\"\n" \ - "2: mov %[size],%%ecx\n" \ - " xor %[lmask_out],%[lmask_out]\n" \ - " rep stosb\n" \ - " lea %[mem],%[ptr]\n" \ - " mov %[lmask_in],%[lmask_out]\n" \ - " jmp 1b\n" \ + "2: inc%z[faults] %[faults]\n" \ + " jmp 3b\n" \ " .previous\n" \ _ASM_EXTABLE(1b, 2b), \ ".byte " pfx "0x0f,0xc7,0x1f\n", \ X86_FEATURE_XSAVES, \ - ASM_OUTPUT2([ptr] "+&D" (ptr), [lmask_out] "+&a" (lmask)), \ - [mem] "m" (*ptr), [lmask_in] "g" (lmask), \ - [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size) \ - : "ecx") - - default: - XRSTOR("0x48,"); - break; - case 4: case 2: - XRSTOR(""); - break; + ASM_OUTPUT2([mem] "+m" (*ptr), [faults] "+g" (faults)), \ + [lmask] "a" (lmask), [hmask] "d" (hmask), \ + [ptr] "D" (ptr)) + + default: + XRSTOR("0x48,"); + break; + case 4: case 2: + XRSTOR(""); + break; #undef XRSTOR + } + if ( likely(faults == prev_faults) ) + break; +#ifndef NDEBUG + gprintk(XENLOG_WARNING, "fault#%u: mxcsr=%08x\n", + faults, ptr->fpu_sse.mxcsr); + gprintk(XENLOG_WARNING, "xs=%016lx xc=%016lx\n", + ptr->xsave_hdr.xstate_bv, ptr->xsave_hdr.xcomp_bv); + gprintk(XENLOG_WARNING, "r0=%016lx r1=%016lx\n", + ptr->xsave_hdr.reserved[0], ptr->xsave_hdr.reserved[1]); + gprintk(XENLOG_WARNING, "r2=%016lx r3=%016lx\n", + ptr->xsave_hdr.reserved[2], ptr->xsave_hdr.reserved[3]); + gprintk(XENLOG_WARNING, "r4=%016lx r5=%016lx\n", + ptr->xsave_hdr.reserved[4], ptr->xsave_hdr.reserved[5]); +#endif + switch ( faults ) + { + case 1: + /* Stage 1: Reset state to be loaded. */ + ptr->xsave_hdr.xstate_bv &= ~mask; + /* + * Also try to eliminate fault reasons, even if this shouldn't be + * needed here (other code should ensure the sanity of the data). + */ + if ( ((mask & XSTATE_SSE) || + ((mask & XSTATE_YMM) && + !(ptr->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED))) ) + ptr->fpu_sse.mxcsr &= mxcsr_mask; + if ( cpu_has_xsaves || cpu_has_xsavec ) + { + ptr->xsave_hdr.xcomp_bv &= this_cpu(xcr0) | this_cpu(xss); + ptr->xsave_hdr.xstate_bv &= ptr->xsave_hdr.xcomp_bv; + ptr->xsave_hdr.xcomp_bv |= XSTATE_COMPACTION_ENABLED; + } + else + { + ptr->xsave_hdr.xstate_bv &= this_cpu(xcr0); + ptr->xsave_hdr.xcomp_bv = 0; + } + memset(ptr->xsave_hdr.reserved, 0, sizeof(ptr->xsave_hdr.reserved)); + continue; + case 2: + /* Stage 2: Reset all state. */ + ptr->fpu_sse.mxcsr = MXCSR_DEFAULT; + ptr->xsave_hdr.xstate_bv = 0; + ptr->xsave_hdr.xcomp_bv = cpu_has_xsaves + ? XSTATE_COMPACTION_ENABLED : 0; + continue; + default: + domain_crash(current->domain); + break; + } } } @@ -496,6 +549,8 @@ void xstate_init(struct cpuinfo_x86 *c) if ( bsp ) { + static typeof(current->arch.xsave_area->fpu_sse) __initdata ctxt; + xfeature_mask = feature_mask; /* * xsave_cntxt_size is the max size required by enabled features. @@ -504,6 +559,10 @@ void xstate_init(struct cpuinfo_x86 *c) xsave_cntxt_size = _xstate_ctxt_size(feature_mask); printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n", __func__, xsave_cntxt_size, xfeature_mask); + + asm ( "fxsave %0" : "=m" (ctxt) ); + if ( ctxt.mxcsr_mask ) + mxcsr_mask = ctxt.mxcsr_mask; } else {