[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default


  • To: <JBeulich@xxxxxxxx>
  • From: <Kevin.Mayer@xxxxxxxx>
  • Date: Thu, 4 Aug 2016 15:08:28 +0000
  • Accept-language: de-DE, en-US
  • Cc: andrew.cooper3@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Delivery-date: Thu, 04 Aug 2016 15:08:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AdHpan9MOz4yjQpsRm+be9rxBdX5KAABXWeAAMyAUGAAAdu7AAA3ibpA///sXYD//lvYcA==
  • Thread-topic: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default

According to the crash-dump ( output of vcpu ) the v->arch.hvm_vmx.host_cr0 is 
" 0 ".
This cannot be the correct result because of

if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) )
    {
        v->arch.hvm_vmx.host_cr0 |= X86_CR0_TS;
        __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
    }
It should at least be 0x8.
Also the v->arch.hvm_vmx.vmcs is " 0 " which I assume leads to the crash.


Since I assumed that somehow the wrong VCPU is used I tried to find the correct 
one:

vcpus gives
   VCID  PCID       VCPU       ST T DOMID      DOMAIN     
>     0     0 ffff8300e7557000 RU I 32767 ffff830c14ee1000
>     1     1 ffff8300e75f2000 RU I 32767 ffff830c14ee1000
      2     2 ffff8300e72fe000 RU I 32767 ffff830c14ee1000
>     3     3 ffff8300e75f1000 RU I 32767 ffff830c14ee1000
>     4     4 ffff8300e75f0000 RU I 32767 ffff830c14ee1000
>     5     5 ffff8300e72fd000 RU I 32767 ffff830c14ee1000
>*    6     6 ffff8300e72fc000 RU I 32767 ffff830c14ee1000
>     7     7 ffff8300e72fb000 RU I 32767 ffff830c14ee1000
>     0     2 ffff8300e72f9000 RU 0     0 ffff830c17e32000
      1     3 ffff8300e72f8000 BL 0     0 ffff830c17e32000
      2     5 ffff8300e755f000 BL 0     0 ffff830c17e32000
      3     0 ffff8300e755e000 BL 0     0 ffff830c17e32000
      4     6 ffff8300e755d000 BL 0     0 ffff830c17e32000
      5     4 ffff8300e755c000 BL 0     0 ffff830c17e32000
      6     7 ffff8300e755b000 BL 0     0 ffff830c17e32000
      7     5 ffff8300e755a000 BL 0     0 ffff830c17e32000
      0     1 ffff8300e6fc7000 BL U   162 ffff830bdee8f000
      0     3 ffff8300e6fc9000 BL U   163 ffff830be20d3000
      0     6 ffff8300e6fc0000 BL U   164 ffff830be8dc9000
      0     0 ffff8300e6fc6000 BL U   165 ffff830bd0cc0000

Since I see the domain ffff830be8dc9000 all over the xen dmesg this should be 
the correct VCPU.
On this CPU the v->arch.hvm_vmx.host_cr0 is 2147811387 (0x 8005003B) which 
corresponds to the cr0 in the xen dmesg.
v->arch.hvm_vmx.vmcs is 0xffff830bd0da1000

crash> x /10x 0xffff830bd0da1000
0xffff830bd0da1000:     0x000000000000000e      0x0000000000000000
0xffff830bd0da1010:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1020:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1030:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1040:     0x0000000000000000      0x0000000000000000

So the vmcs revision id is 0xe.
rdmsr 0x480 (the IA32_VMX_BASIC MSR ) gives da04000000000e which confirms the 
revision ID.
Size should be 0x400 bytes.

crash> x /130x 0xffff830bd0da1000
0xffff830bd0da1000:     0x000000000000000e      0x0000000000000000
0xffff830bd0da1010:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1020:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1030:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1040:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1050:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1060:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1070:     0x0000000000000000      0x0000000bd0da3000
0xffff830bd0da1080:     0x0000000c17e36000      0x0000000000000000
0xffff830bd0da1090:     0x0000000000000000      0x0000000000000000
0xffff830bd0da10a0:     0x00000000e7512000      0x00000000e7513000
0xffff830bd0da10b0:     0x0000000bd0da0000      0x0000000000000000
0xffff830bd0da10c0:     0x0000000000000000      0x0000000000000000
0xffff830bd0da10d0:     0x0000000000000000      0x0000006fedea809b
0xffff830bd0da10e0:     0x00000001a379e000      0x0000000610f9101e
0xffff830bd0da10f0:     0x0000000000000000      0xffffffffffffffff
0xffff830bd0da1100:     0x0000000000000000      0x0007010600070106
0xffff830bd0da1110:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1120:     0x0000006bb6a075fa      0x000600420000003f
0xffff830bd0da1130:     0x0000000000000000      0x000fefff00000000
0xffff830bd0da1140:     0x0000000000000000      0x00000000000051ff
0xffff830bd0da1150:     0x0000000000000041      0x0000000000000000
0xffff830bd0da1160:     0x0000000000000000      0x0000000c00000000
0xffff830bd0da1170:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1180:     0x0000000000000001      0x0000000000000000
0xffff830bd0da1190:     0x0000000800000000      0x0000000000000000
0xffff830bd0da11a0:     0x0000000000000001      0x0000000000000096
0xffff830bd0da11b0:     0xffff82d0802bc208      0x00000000806f6dbc
0xffff830bd0da11c0:     0x0000000000000000      0x0000000000000400
0xffff830bd0da11d0:     0x0000000080550f34      0x00000000f0e48161
0xffff830bd0da11e0:     0x0000000000000246      0x0000000000000000
0xffff830bd0da11f0:     0x00000000f79c3000      0x00000000804de6f0
0xffff830bd0da1200:     0x0000000000000023      0x0000000000000000
0xffff830bd0da1210:     0x00c0f300ffffffff      0x0000000000000008
0xffff830bd0da1220:     0x0000000000000000      0x00c09b00ffffffff
0xffff830bd0da1230:     0x0000000000000010      0x0000000000000000
0xffff830bd0da1240:     0x00c09300ffffffff      0x0000000000000023
0xffff830bd0da1250:     0x0000000000000000      0x00c0f300ffffffff
0xffff830bd0da1260:     0x0000000000000030      0x00000000ffdff000
0xffff830bd0da1270:     0x00c0930000001fff      0x0000000000000000
0xffff830bd0da1280:     0x0000000000000000      0x01c00000ffffffff
0xffff830bd0da1290:     0x0000000000000000      0x0000000000000000
0xffff830bd0da12a0:     0x01c00000ffffffff      0x0000000000000028
0xffff830bd0da12b0:     0x0000000080042000      0x00008b00000020ab
0xffff830bd0da12c0:     0x000000008003f000      0x000000008003f400
0xffff830bd0da12d0:     0x000007ff000003ff      0x000000008001003b
0xffff830bd0da12e0:     0x0000000000039000      0x00000000000026d9
0xffff830bd0da12f0:     0x000000000000dc3c      0x0000000000000000
0xffff830bd0da1300:     0x0000e00800000000      0x0000000000000000
0xffff830bd0da1310:     0x0000000000000000      0x000000000000e040
0xffff830bd0da1320:     0x0000050100070406      0x0000000000000000
0xffff830bd0da1330:     0x0000000000000000      0x0000000080050033
0xffff830bd0da1340:     0x00000001bd665000      0x00000000000026e0
0xffff830bd0da1350:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1360:     0xffff830c17e38c80      0xffff830617fd3000
0xffff830bd0da1370:     0xffff830617fcf000      0xffff830617fd7fc0
0xffff830bd0da1380:     0xffff82d08024e150      0xffff830617fd7f90
0xffff830bd0da1390:     0xffff82d080201bb0      0x000000000000e008
0xffff830bd0da13a0:     0x0000006000000000      0x0000000000000000
0xffff830bd0da13b0:     0x0000000000000000      0x0000000000000000
0xffff830bd0da13c0:     0xffffffffffffffff      0xffffffffffffffff
0xffff830bd0da13d0:     0x000000008001003b      0x00000000000006d9
0xffff830bd0da13e0:     0x0000000000000000      0x0000000000000000
0xffff830bd0da13f0:     0x0000000000000000      0x0000000000000000
0xffff830bd0da1400:     0x0000000000000000      0x0000000000000000

I don't quite understand the Intel developer manual at this point. How do I 
have to read this data?

Since if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) ) must be true I assume the 
__vmwrite tries to | 0x8 into the host_cr0 leading to the 0x0000000080050033 
for the current host_cr0 ( or better the 0x80050033 ).
Or at least this is what I think was intended to happen.

> -----Ursprüngliche Nachricht-----
> Von: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Gesendet: Mittwoch, 3. August 2016 15:54
> An: Mayer, Kevin <Kevin.Mayer@xxxxxxxx>
> Cc: andrew.cooper3@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabled by default
> 
> >>> On 03.08.16 at 15:24, <Kevin.Mayer@xxxxxxxx> wrote:
> > I got around to take a closer look at the crash dump today.
> >
> > tl;dr:
> > You were right, vmx_vmenter_helper is not called at all in the call stack.
> > The real reason behind the [<ffff82d0801fd23a>]
> > vmx_vmenter_helper+0x27e/0x30a should be a failed
> __vmwrite(HOST_CR0,
> > v->arch.hvm_vmx.host_cr0); in static void vmx_fpu_leave(struct vcpu
> > *v).
> 
> Ah - that's what you get for not using most recent code, and what I get for
> not considering the effect of you being on 4.6.x. In any event - the call 
> stack
> is then fine, and you'll want to figure out which bit(s) of the new CR0 value
> are in conflict with the rest of the active VMCS.
> 
> Jan
____________
Virus checked by G Data MailSecurity
Version: AVA 25.7724 dated 04.08.2016
Virus news: www.antiviruslab.com

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.