* HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 @ 2015-11-12 1:08 Atom2 2015-11-12 12:52 ` Jan Beulich 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-12 1:08 UTC (permalink / raw) To: xen-devel Hi guys, today I have upgraded from XEN 4.5.1 to XEN 4.5.2 and also upgraded the dom0 kernel from 3.18.9 to 4.1.7 After the upgrade HVM domUs appear to no longer work - regardless of the dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV domUs, however, work just fine as before on both dom0 kernels. xl dmesg shows the following information after the first crashed HVM domU which is started as part of the machine booting up: ===== start xl dmesg output ===== Xen 4.5.2 (XEN) Xen version 4.5.2 (@myhomeismycastle.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=n Wed Nov 11 13:00:00 CET 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder ucode=-1 loglvl=warning guest_loglvl=none/warning dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009d800 (usable) (XEN) 000000000009d800 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040000000 (usable) (XEN) 0000000040000000 - 0000000040200000 (reserved) (XEN) 0000000040200000 - 00000000db9f0000 (usable) (XEN) 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) 00000000dc651000 - 00000000dc652000 (usable) (XEN) 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) 00000000dc695000 - 00000000dcdba000 (usable) (XEN) 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) 00000000dcff2000 - 00000000dd000000 (usable) (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) 00000000f8000000 - 00000000fc000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fed00000 - 00000000fed04000 (reserved) (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ff000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000081e600000 (usable) (XEN) ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) ACPI: FACS DC1F7F80, 0040 (XEN) ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) System RAM: 32674MB (33458948kB) (XEN) Domain heap initialised (XEN) ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) Processor #0 6:10 APIC version 21 (XEN) Processor #2 6:10 APIC version 21 (XEN) Processor #4 6:10 APIC version 21 (XEN) Processor #6 6:10 APIC version 21 (XEN) Processor #1 6:10 APIC version 21 (XEN) Processor #3 6:10 APIC version 21 (XEN) Processor #5 6:10 APIC version 21 (XEN) Processor #7 6:10 APIC version 21 (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2394.643 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) Brought up 8 CPUs (XEN) tmem: initialized comp=1 dedup=1 tze=0 (XEN) Dom0 has maximum 792 PIRQs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) Start info: ffffffff82400000->ffffffff824004b4 (XEN) Page tables: ffffffff82401000->ffffffff82418000 (XEN) Boot stack: ffffffff82418000->ffffffff82419000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff818e31f0 (XEN) Dom0 has maximum 8 VCPUs (XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 316kB init memory. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca73000 to 0xffffffff81646d10. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca73080 to 0xffffffff81648e70. (XEN) Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) ************* VMCS Area ************** (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) CR3: actual=0x0000000000800000, target_count=0 (XEN) target0=0000000000000000, target1=0000000000000000 (XEN) target2=0000000000000000, target3=0000000000000000 (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = 0x0000000100000000 (0x0000000100000000) (XEN) RFLAGS=0x0000000000000006 (0x0000000000000006) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) CS: sel=0x0008, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000 (XEN) DS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) SS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) ES: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) FS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) GS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) GDTR: limit=0x00000037, base=0x00000000000f6d80 (XEN) LDTR: sel=0x0000, attr=0x00082, limit=0x00000000, base=0x0000000000000000 (XEN) IDTR: limit=0x00000000, base=0x00000000000f6dbe (XEN) TR: sel=0x0000, attr=0x0008b, limit=0x000000ff, base=0x0000000000000000 (XEN) Guest PAT = 0x0007040600070406 (XEN) TSC Offset = ffffffe7c228bb48 (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) Interruptibility=0000 ActivityState=0000 (XEN) *** Host State *** (XEN) RSP = 0xffff8308063fff90 RIP = 0xffff82d0801f46a0 (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff83080ca88c80 (XEN) GDTBase=ffff83080ca7c000 IDTBase=ffff83080ca8d000 (XEN) CR0=000000008005003b CR3=000000070bf21000 CR4=00000000000426f0 (XEN) Sysenter RSP=ffff8308063fffc0 CS:RIP=e008:ffff82d080235550 (XEN) Host PAT = 0x0000050100070406 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a065fe SecondaryExec=000000eb (XEN) EntryControls=000051ff ExitControls=000fefff (XEN) ExceptionBitmap=000400c0 (XEN) VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) reason=80000021 qualification=00000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TPR Threshold = 0x00 (XEN) EPT pointer = 0x000000070bf1f01e (XEN) Virtual processor ID = 0x0002 (XEN) ************************************** (XEN) domain_crash called from vmx.c:2511 (XEN) Domain 1 (vcpu#0) crashed on cpu#6: (XEN) ----[ Xen-4.5.2 x86_64 debug=n Not tainted ]---- (XEN) CPU: 6 (XEN) RIP: 0008:[<0000000100000000>] (XEN) RFLAGS: 0000000000000006 CONTEXT: hvm guest (d1v0) (XEN) rax: 0000000000000000 rbx: 0000000000000000 rcx: 00000000ffff1720 (XEN) rdx: 0000000000000059 rsi: 0000000000000059 rdi: 0000000000000000 (XEN) rbp: 0000000000000000 rsp: 0000000000006fdc r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) cr3: 0000000000800000 cr2: 0000000000000000 (XEN) ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 ===== end xl dmesg output ===== It is probably also worth pointing out again that this crash happens with both kernels, 3.18.9 and 4.1.7; the only obvious differenc (other than slight address differences) between 3.18.9 and 4.1.7 are the following lines in xl dmesg above which only show up on 4.1.7: (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca73000 to 0xffffffff81646d10. (XEN) traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca73080 to 0xffffffff81648e70. The configuration file for the crashing HVM domain contains nothing fancy and looks as follows: ===== start configuration file ===== builder = 'hvm' cpus = '2-7' vcpus = 2 cpu_weight = 512 memory = 640 name = 'pfsense' disk = [ 'vdev=xvda,format=raw,access=rw,target=/etc/xen/guests/disk.d/pfsense.disk' ] vif = [ 'mac=00:16:3e:a1:64:01,bridge=xenbr0,type=vif,vifname=pfsense.0,script=vif-bridge.noTXoffload' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' localtime = 0 boot = 'c' vnc = 1 vnclisten = '127.0.0.1' vncpasswd = '' keymap = 'de' nographic = 1 serial = 'pty' nx = 1 pci = [ '04:00.0', '0a:08.0', '0a:0b.0' ] ===== end configuration file ===== The crash seems to not be related to this domU; there's another HVM domU which also crashes with a similar message. Prior to the upgrade this has all worked flawlessly for a number of months on 4.5.1. Any insight on what's going on and how to return to proper operation would greatly be appreciated. Many thanks in advance, Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 1:08 HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 Atom2 @ 2015-11-12 12:52 ` Jan Beulich 2015-11-12 13:01 ` Andrew Cooper 2015-11-12 14:12 ` Atom2 0 siblings, 2 replies; 43+ messages in thread From: Jan Beulich @ 2015-11-12 12:52 UTC (permalink / raw) To: Atom2; +Cc: xen-devel >>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: > After the upgrade HVM domUs appear to no longer work - regardless of the > dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV > domUs, however, work just fine as before on both dom0 kernels. > > xl dmesg shows the following information after the first crashed HVM > domU which is started as part of the machine booting up: >[...] > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest > state (0). > (XEN) ************* VMCS Area ************** > (XEN) *** Guest State *** > (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, > gh_mask=ffffffffffffffff > (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, > gh_mask=ffffffffffffffff > (XEN) CR3: actual=0x0000000000800000, target_count=0 > (XEN) target0=0000000000000000, target1=0000000000000000 > (XEN) target2=0000000000000000, target3=0000000000000000 > (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = > 0x0000000100000000 (0x0000000100000000) Other than RIP looking odd for a guest still in non-paged protected mode I can't seem to spot anything wrong with guest state. Considering that there was just a single HVM-related commit between the two releases (which looks completely unrelated) I wonder whether you're observing a problem that's a side effect of something else, e.g. a build system change (compiler update or alike). If that can be ruled out, I guess the only chance would be for you to bisect for the offending commit. Are you observing this on more than one kind of system? Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 12:52 ` Jan Beulich @ 2015-11-12 13:01 ` Andrew Cooper 2015-11-12 14:29 ` Atom2 2015-11-12 14:12 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-12 13:01 UTC (permalink / raw) To: Jan Beulich, Atom2; +Cc: xen-devel On 12/11/15 12:52, Jan Beulich wrote: >>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >> After the upgrade HVM domUs appear to no longer work - regardless of the >> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >> domUs, however, work just fine as before on both dom0 kernels. >> >> xl dmesg shows the following information after the first crashed HVM >> domU which is started as part of the machine booting up: >> [...] >> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >> state (0). >> (XEN) ************* VMCS Area ************** >> (XEN) *** Guest State *** >> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >> gh_mask=ffffffffffffffff >> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >> gh_mask=ffffffffffffffff >> (XEN) CR3: actual=0x0000000000800000, target_count=0 >> (XEN) target0=0000000000000000, target1=0000000000000000 >> (XEN) target2=0000000000000000, target3=0000000000000000 >> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >> 0x0000000100000000 (0x0000000100000000) > Other than RIP looking odd for a guest still in non-paged protected > mode I can't seem to spot anything wrong with guest state. odd? That will be the source of the failure. Out of long mode, the upper 32bit of %rip should all be zero, and it should not be possible to set any of them. I suspect that the guest has exited for emulation, and there has been a bad update to %rip. The alternative (which I hope is not the case) is that there is a hardware errata which allows the guest to accidentally get it self into this condition. Are you able to rerun with a debug build of the hypervisor? ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 13:01 ` Andrew Cooper @ 2015-11-12 14:29 ` Atom2 2015-11-12 15:32 ` Jan Beulich 2015-11-12 16:43 ` Andrew Cooper 0 siblings, 2 replies; 43+ messages in thread From: Atom2 @ 2015-11-12 14:29 UTC (permalink / raw) To: Andrew Cooper, Jan Beulich; +Cc: xen-devel Hi Andrew, thanks for your reply. Answers are inline further down. Am 12.11.15 um 14:01 schrieb Andrew Cooper: > On 12/11/15 12:52, Jan Beulich wrote: >>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>> After the upgrade HVM domUs appear to no longer work - regardless of the >>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>> domUs, however, work just fine as before on both dom0 kernels. >>> >>> xl dmesg shows the following information after the first crashed HVM >>> domU which is started as part of the machine booting up: >>> [...] >>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>> state (0). >>> (XEN) ************* VMCS Area ************** >>> (XEN) *** Guest State *** >>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>> gh_mask=ffffffffffffffff >>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>> gh_mask=ffffffffffffffff >>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>> (XEN) target0=0000000000000000, target1=0000000000000000 >>> (XEN) target2=0000000000000000, target3=0000000000000000 >>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>> 0x0000000100000000 (0x0000000100000000) >> Other than RIP looking odd for a guest still in non-paged protected >> mode I can't seem to spot anything wrong with guest state. > odd? That will be the source of the failure. > > Out of long mode, the upper 32bit of %rip should all be zero, and it > should not be possible to set any of them. > > I suspect that the guest has exited for emulation, and there has been a > bad update to %rip. The alternative (which I hope is not the case) is > that there is a hardware errata which allows the guest to accidentally > get it self into this condition. > > Are you able to rerun with a debug build of the hypervisor? Given that I am compiling from source under gentoo and provided you lend me a helping hand in case I get stuck, I am confident that this is possible. gentoo has three xen packages (they call those ebuilds) as follows app-emulation/xen app-emulation/xen-tools app-emulation/pvgrub all of which are installed on my system. The former two offer a debug USE-flag and I assume that debug code for the latter is not required as this is for (the still working) PV domUs only. Furthermore as you are talking about the hypervisor, I guess it is safe to assume that it is app-emulation/xen and not xen-tools. Right? BTW: The description of the debug USE flag reads as follows: Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces I assume that backtraces are probably not required to get things moving. Another question is whether prior to enabling the debug USE flag it might make sense to re-compile with gcc-4.8.5 (please see my previous list reply) to rule out any compiler related issues. Jan, Andrew - what are your thoughts? Many thanks Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 14:29 ` Atom2 @ 2015-11-12 15:32 ` Jan Beulich 2015-11-12 16:43 ` Andrew Cooper 1 sibling, 0 replies; 43+ messages in thread From: Jan Beulich @ 2015-11-12 15:32 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, xen-devel >>> On 12.11.15 at 15:29, <ariel.atom2@web2web.at> wrote: > Another question is whether prior to enabling the debug USE flag it > might make sense to re-compile with gcc-4.8.5 (please see my previous > list reply) to rule out any compiler related issues. Jan, Andrew - what > are your thoughts? The order of things you try is entirely up to you. Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 14:29 ` Atom2 2015-11-12 15:32 ` Jan Beulich @ 2015-11-12 16:43 ` Andrew Cooper 2015-11-12 23:00 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-12 16:43 UTC (permalink / raw) To: Atom2, Jan Beulich; +Cc: xen-devel On 12/11/15 14:29, Atom2 wrote: > Hi Andrew, > thanks for your reply. Answers are inline further down. > > Am 12.11.15 um 14:01 schrieb Andrew Cooper: >> On 12/11/15 12:52, Jan Beulich wrote: >>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>> After the upgrade HVM domUs appear to no longer work - regardless >>>> of the >>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>> domUs, however, work just fine as before on both dom0 kernels. >>>> >>>> xl dmesg shows the following information after the first crashed HVM >>>> domU which is started as part of the machine booting up: >>>> [...] >>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>> state (0). >>>> (XEN) ************* VMCS Area ************** >>>> (XEN) *** Guest State *** >>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>> gh_mask=ffffffffffffffff >>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>> gh_mask=ffffffffffffffff >>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>> 0x0000000100000000 (0x0000000100000000) >>> Other than RIP looking odd for a guest still in non-paged protected >>> mode I can't seem to spot anything wrong with guest state. >> odd? That will be the source of the failure. >> >> Out of long mode, the upper 32bit of %rip should all be zero, and it >> should not be possible to set any of them. >> >> I suspect that the guest has exited for emulation, and there has been a >> bad update to %rip. The alternative (which I hope is not the case) is >> that there is a hardware errata which allows the guest to accidentally >> get it self into this condition. >> >> Are you able to rerun with a debug build of the hypervisor? > Given that I am compiling from source under gentoo and provided you > lend me a helping hand in case I get stuck, I am confident that this > is possible. > > gentoo has three xen packages (they call those ebuilds) as follows > app-emulation/xen > app-emulation/xen-tools > app-emulation/pvgrub > all of which are installed on my system. The former two offer a debug > USE-flag and I assume that debug code for the latter is not required > as this is for (the still working) PV domUs only. Furthermore as you > are talking about the hypervisor, I guess it is safe to assume that it > is app-emulation/xen and not xen-tools. Right? I would guess so. > > BTW: The description of the debug USE flag reads as follows: > Enable extra debug codepaths, like asserts and extra output. If you > want to get meaningful backtraces see > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces > I assume that backtraces are probably not required to get things moving. By the sounds of it, the debug USE flag is what you want. > > Another question is whether prior to enabling the debug USE flag it > might make sense to re-compile with gcc-4.8.5 (please see my previous > list reply) to rule out any compiler related issues. Jan, Andrew - > what are your thoughts? First of all, check whether the compiler makes a difference on 4.5.2 If both compiles result in a guest crashing in that manner, test a debug Xen to see if any assertions/errors are encountered just before the guest crashes. ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 16:43 ` Andrew Cooper @ 2015-11-12 23:00 ` Atom2 2015-11-13 7:25 ` Jan Beulich 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-12 23:00 UTC (permalink / raw) To: Andrew Cooper, Jan Beulich; +Cc: xen-devel [-- Attachment #1: Type: text/plain, Size: 3759 bytes --] Am 12.11.15 um 17:43 schrieb Andrew Cooper: > On 12/11/15 14:29, Atom2 wrote: >> Hi Andrew, >> thanks for your reply. Answers are inline further down. >> >> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>> of the >>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>> >>>>> xl dmesg shows the following information after the first crashed HVM >>>>> domU which is started as part of the machine booting up: >>>>> [...] >>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>> state (0). >>>>> (XEN) ************* VMCS Area ************** >>>>> (XEN) *** Guest State *** >>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>> gh_mask=ffffffffffffffff >>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>> gh_mask=ffffffffffffffff >>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>> 0x0000000100000000 (0x0000000100000000) >>>> Other than RIP looking odd for a guest still in non-paged protected >>>> mode I can't seem to spot anything wrong with guest state. >>> odd? That will be the source of the failure. >>> >>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>> should not be possible to set any of them. >>> >>> I suspect that the guest has exited for emulation, and there has been a >>> bad update to %rip. The alternative (which I hope is not the case) is >>> that there is a hardware errata which allows the guest to accidentally >>> get it self into this condition. >>> >>> Are you able to rerun with a debug build of the hypervisor? >> [snip] >> Another question is whether prior to enabling the debug USE flag it >> might make sense to re-compile with gcc-4.8.5 (please see my previous >> list reply) to rule out any compiler related issues. Jan, Andrew - >> what are your thoughts? > First of all, check whether the compiler makes a difference on 4.5.2 Hi Andrew, I changed the compiler and there was no change to the better: Unfortunately the HVM domU is still crashing with a similar error message as soon as it is being started. > If both compiles result in a guest crashing in that manner, test a debug > Xen to see if any assertions/errors are encountered just before the > guest crashes. > As the compiler did not make any difference, I enabled the debug USE flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console to capture output. Unfortunately I did not get very far and things become even stranger: This time the system did not even finnish the boot process, but rather hard-stopped pretty early with a message reading "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile is attached as "serial log.txt". As this happened immediately after the CPU microcode update, I thought there might be a connection and disabled the microcode update. After the next reboot it seemed as if the boot process got a bit further as evidenced by a few more lines in the log file (those between lines 136 and 197 in the second log file named "serial log no ucode.txt"), but in the end it finnished off with an identical error message (only the CPU # was different this time, but that number seems to change between boots anyways). I hope that makes some sense to you. Many thanks for your support and best regards Atom2 [-- Attachment #2: serial log.txt --] [-- Type: text/plain, Size: 8257 bytes --] Xen 4.5.2 (XEN) Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Thu Nov 12 21:30:05 CET 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009d800 (usable) (XEN) 000000000009d800 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040000000 (usable) (XEN) 0000000040000000 - 0000000040200000 (reserved) (XEN) 0000000040200000 - 00000000db9f0000 (usable) (XEN) 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) 00000000dc651000 - 00000000dc652000 (usable) (XEN) 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) 00000000dc695000 - 00000000dcdba000 (usable) (XEN) 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) 00000000dcff2000 - 00000000dd000000 (usable) (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) 00000000f8000000 - 00000000fc000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fed00000 - 00000000fed04000 (reserved) (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ff000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000081e600000 (usable) (XEN) ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) ACPI: FACS DC1F7F80, 0040 (XEN) ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) System RAM: 32674MB (33458948kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000081e600000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000fd8d0 (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) Processor #4 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) Processor #6 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) Processor #1 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) Processor #3 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) Processor #5 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) Processor #7 6:10 APIC version 21 (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2397.844 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) alt table ffff82d0802e8810 -> ffff82d0802e9830 (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) PCI: MCFG area at f8000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-3f (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) TSC deadline timer enabled (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) mwait-idle: MWAIT substates: 0x1120 (XEN) mwait-idle: v0.4 model 0x2a (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) *** DOUBLE FAULT *** (XEN) ----[ Xen-4.5.2 x86_64 debug=y Not tainted ]---- (XEN) CPU: 6 (XEN) RIP: e008:[<ffff82d08017658c>] do_IRQ+0x15/0x64c (XEN) RFLAGS: 0000000000010083 CONTEXT: hypervisor (XEN) rax: 0000000000000000 rbx: 0000000000000028 rcx: 0000000000000000 (XEN) rdx: 0000000000000002 rsi: 0000000000000028 rdi: ffff8308063e6c68 (XEN) rbp: ffff8308063e6c58 rsp: ffff8308063e5bd8 r8: 0000000000000000 (XEN) r9: 0000000000000039 r10: ffff82d08033a2f8 r11: ffff82d08033a2e8 (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000002 (XEN) r15: ffff83080ca74000 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) cr3: 00000000db69f000 cr2: ffff8308063e5bc8 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Valid stack range: ffff8308063e6000-ffff8308063e8000, sp=ffff8308063e5bd8, tss.esp0=ffff8308063e7fc0 (XEN) No stack overflow detected. Skipping stack trace. (XEN) (XEN) **************************************** (XEN) Panic on CPU 6: (XEN) DOUBLE FAULT -- system shutdown (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... [-- Attachment #3: serial log no ucode.txt --] [-- Type: text/plain, Size: 11432 bytes --] Xen 4.5.2 (XEN) Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Thu Nov 12 21:30:05 CET 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 2 MBR signatures (XEN) Found 2 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009d800 (usable) (XEN) 000000000009d800 - 00000000000a0000 (reserved) (XEN) 00000000000e0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040000000 (usable) (XEN) 0000000040000000 - 0000000040200000 (reserved) (XEN) 0000000040200000 - 00000000db9f0000 (usable) (XEN) 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) 00000000dc651000 - 00000000dc652000 (usable) (XEN) 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) 00000000dc695000 - 00000000dcdba000 (usable) (XEN) 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) 00000000dcff2000 - 00000000dd000000 (usable) (XEN) 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) 00000000f8000000 - 00000000fc000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fed00000 - 00000000fed04000 (reserved) (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ff000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000081e600000 (usable) (XEN) ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) ACPI: FACS DC1F7F80, 0040 (XEN) ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) System RAM: 32674MB (33458948kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000081e600000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000fd8d0 (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) Processor #4 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) Processor #6 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) Processor #1 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) Processor #3 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) Processor #5 6:10 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) Processor #7 6:10 APIC version 21 (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) Switched to APIC driver x2apic_cluster. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2394.622 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) alt table ffff82d0802e8810 -> ffff82d0802e9830 (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) PCI: MCFG area at f8000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-3f (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Interrupt Remapping enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) TSC deadline timer enabled (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 64 KiB. (XEN) mwait-idle: MWAIT substates: 0x1120 (XEN) mwait-idle: v0.4 model 0x2a (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) Brought up 8 CPUs (XEN) tmem: initialized comp=1 dedup=1 tze=0 (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) Dom0 has maximum 792 PIRQs (XEN) Multiple initrd candidates, picking module #1 (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x65033b (XEN) elf_parse_binary: phdr: paddr=0x1651000 memsz=0x1e5000 (XEN) elf_parse_binary: phdr: paddr=0x1836000 memsz=0x98000 (XEN) elf_parse_binary: phdr: paddr=0x18ce000 memsz=0x1000 (XEN) elf_parse_binary: phdr: paddr=0x18cf000 memsz=0x13c98 (XEN) elf_parse_binary: phdr: paddr=0x18e3000 memsz=0x3d000 (XEN) elf_parse_binary: phdr: paddr=0x1920000 memsz=0x1120 (XEN) elf_parse_binary: phdr: paddr=0x1922000 memsz=0x2de000 (XEN) elf_parse_binary: memory: 0x1000000 -> 0x1c00000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff818e31f0 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" (XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: MOD_START_PFN = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81c00000 (XEN) virt_entry = 0xffffffff818e31f0 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) Start info: ffffffff82400000->ffffffff824004b4 (XEN) Page tables: ffffffff82401000->ffffffff82418000 (XEN) Boot stack: ffffffff82418000->ffffffff82419000 (XEN) TOTAL: ffffffff80000000->ffffffff82800000 (XEN) ENTRY ADDRESS: ffffffff818e31f0 (XEN) Dom0 has maximum 8 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8165033b (XEN) elf_load_binary: phdr 1 at 0xffffffff81651000 -> 0xffffffff81836000 (XEN) elf_load_binary: phdr 2 at 0xffffffff81836000 -> 0xffffffff818ce000 (XEN) elf_load_binary: phdr 3 at 0xffffffff818ce000 -> 0xffffffff818cf000 (XEN) elf_load_binary: phdr 4 at 0xffffffff818cf000 -> 0xffffffff818e2c98 (XEN) elf_load_binary: phdr 5 at 0xffffffff818e3000 -> 0xffffffff81920000 (XEN) elf_load_binary: phdr 6 at 0xffffffff81920000 -> 0xffffffff81921120 (XEN) elf_load_binary: phdr 7 at 0xffffffff81922000 -> 0xffffffff819dd000 (XEN) *** DOUBLE FAULT *** (XEN) ----[ Xen-4.5.2 x86_64 debug=y Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e008:[<ffff82d08017658c>] do_IRQ+0x15/0x64c (XEN) RFLAGS: 0000000000010083 CONTEXT: hypervisor (XEN) rax: 000000378c762d00 rbx: 0000000000000003 rcx: 0000000000196bd0 (XEN) rdx: 000000000016c015 rsi: 00000000a0789100 rdi: ffff83080ca96d38 (XEN) rbp: ffff83080ca96d28 rsp: ffff83080ca95ca8 r8: ffff82d080339380 (XEN) r9: 0000000000000000 r10: 00000000000000d8 r11: 00000000000000d8 (XEN) r12: ffff82d08028a3c0 r13: 0000000000000001 r14: 0000000000000002 (XEN) r15: ffff83080caa8830 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) cr3: 00000000db69f000 cr2: ffff83080ca95c98 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Valid stack range: ffff83080ca96000-ffff83080ca98000, sp=ffff83080ca95ca8, tss.esp0=ffff83080ca97fc0 (XEN) No stack overflow detected. Skipping stack trace. (XEN) (XEN) **************************************** (XEN) Panic on CPU 3: (XEN) DOUBLE FAULT -- system shutdown (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... [-- Attachment #4: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 23:00 ` Atom2 @ 2015-11-13 7:25 ` Jan Beulich 2015-11-13 10:09 ` Andrew Cooper 0 siblings, 1 reply; 43+ messages in thread From: Jan Beulich @ 2015-11-13 7:25 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, xen-devel >>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: > Am 12.11.15 um 17:43 schrieb Andrew Cooper: >> On 12/11/15 14:29, Atom2 wrote: >>> Hi Andrew, >>> thanks for your reply. Answers are inline further down. >>> >>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>> of the >>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>> >>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>> domU which is started as part of the machine booting up: >>>>>> [...] >>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>> state (0). >>>>>> (XEN) ************* VMCS Area ************** >>>>>> (XEN) *** Guest State *** >>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>> gh_mask=ffffffffffffffff >>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>> gh_mask=ffffffffffffffff >>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>> 0x0000000100000000 (0x0000000100000000) >>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>> mode I can't seem to spot anything wrong with guest state. >>>> odd? That will be the source of the failure. >>>> >>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>> should not be possible to set any of them. >>>> >>>> I suspect that the guest has exited for emulation, and there has been a >>>> bad update to %rip. The alternative (which I hope is not the case) is >>>> that there is a hardware errata which allows the guest to accidentally >>>> get it self into this condition. >>>> >>>> Are you able to rerun with a debug build of the hypervisor? >>> [snip] >>> Another question is whether prior to enabling the debug USE flag it >>> might make sense to re-compile with gcc-4.8.5 (please see my previous >>> list reply) to rule out any compiler related issues. Jan, Andrew - >>> what are your thoughts? >> First of all, check whether the compiler makes a difference on 4.5.2 > Hi Andrew, > I changed the compiler and there was no change to the better: > Unfortunately the HVM domU is still crashing with a similar error > message as soon as it is being started. >> If both compiles result in a guest crashing in that manner, test a debug >> Xen to see if any assertions/errors are encountered just before the >> guest crashes. >> > As the compiler did not make any difference, I enabled the debug USE > flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console > to capture output. Unfortunately I did not get very far and things > become even stranger: This time the system did not even finnish the boot > process, but rather hard-stopped pretty early with a message reading > "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile > is attached as "serial log.txt". > > As this happened immediately after the CPU microcode update, I thought > there might be a connection and disabled the microcode update. After the > next reboot it seemed as if the boot process got a bit further as > evidenced by a few more lines in the log file (those between lines 136 > and 197 in the second log file named "serial log no ucode.txt"), but in > the end it finnished off with an identical error message (only the CPU # > was different this time, but that number seems to change between boots > anyways). > > I hope that makes some sense to you. Not really, other than now even more suspecting bad hardware or something fundamentally wrong with your build. Did you retry with a freshly built 4.5.1? Could you alternatively try with a known good build of 4.5.2 (e.g. from osstest)? Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-13 7:25 ` Jan Beulich @ 2015-11-13 10:09 ` Andrew Cooper 2015-11-14 0:16 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-13 10:09 UTC (permalink / raw) To: Atom2; +Cc: Jan Beulich, xen-devel [-- Attachment #1: Type: text/plain, Size: 5135 bytes --] On 13/11/15 07:25, Jan Beulich wrote: >>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>> On 12/11/15 14:29, Atom2 wrote: >>>> Hi Andrew, >>>> thanks for your reply. Answers are inline further down. >>>> >>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>> of the >>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>> >>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>> domU which is started as part of the machine booting up: >>>>>>> [...] >>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>> state (0). >>>>>>> (XEN) ************* VMCS Area ************** >>>>>>> (XEN) *** Guest State *** >>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>> gh_mask=ffffffffffffffff >>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>> gh_mask=ffffffffffffffff >>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>> mode I can't seem to spot anything wrong with guest state. >>>>> odd? That will be the source of the failure. >>>>> >>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>> should not be possible to set any of them. >>>>> >>>>> I suspect that the guest has exited for emulation, and there has been a >>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>> that there is a hardware errata which allows the guest to accidentally >>>>> get it self into this condition. >>>>> >>>>> Are you able to rerun with a debug build of the hypervisor? >>>> [snip] >>>> Another question is whether prior to enabling the debug USE flag it >>>> might make sense to re-compile with gcc-4.8.5 (please see my previous >>>> list reply) to rule out any compiler related issues. Jan, Andrew - >>>> what are your thoughts? >>> First of all, check whether the compiler makes a difference on 4.5.2 >> Hi Andrew, >> I changed the compiler and there was no change to the better: >> Unfortunately the HVM domU is still crashing with a similar error >> message as soon as it is being started. >>> If both compiles result in a guest crashing in that manner, test a debug >>> Xen to see if any assertions/errors are encountered just before the >>> guest crashes. >>> >> As the compiler did not make any difference, I enabled the debug USE >> flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console >> to capture output. Unfortunately I did not get very far and things >> become even stranger: This time the system did not even finnish the boot >> process, but rather hard-stopped pretty early with a message reading >> "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile >> is attached as "serial log.txt". >> >> As this happened immediately after the CPU microcode update, I thought >> there might be a connection and disabled the microcode update. After the >> next reboot it seemed as if the boot process got a bit further as >> evidenced by a few more lines in the log file (those between lines 136 >> and 197 in the second log file named "serial log no ucode.txt"), but in >> the end it finnished off with an identical error message (only the CPU # >> was different this time, but that number seems to change between boots >> anyways). >> >> I hope that makes some sense to you. > Not really, other than now even more suspecting bad hardware or > something fundamentally wrong with your build. Did you retry with > a freshly built 4.5.1? Could you alternatively try with a known good > build of 4.5.2 (e.g. from osstest)? Agreed. Double faults indicate that the exception handing entry points are not set up in an appropriate state. Something is definitely wrong with either the compiled binary or the hardware. Several questions and lines of investigation: Is this straight Xen 4.5.1 and 2, or do Gentoo have their own patches on top? On repeated attempts, are the details of the double fault identical (other than the cpu), or does it move around (i.e. always do_IRQ+0x15) Can you boot with console_timestamps=boot on the command line in the future. This will put Linux-sytle timestamps on log messages. Can you also compile in the attached patch? I haven't quite got it suitable for inclusion upstream yet, but it will also dump the instruction stream under the fault. Finally, can you disassemble the xen-syms which results from the debug build and paste the start of do_IRQ. (i.e. `gdb xen-syms` and "disass do_IRQ") ~Andrew [-- Attachment #2: 0001-x86-traps-Dump-instruction-stream-in-show_execution_.patch --] [-- Type: text/x-diff, Size: 3819 bytes --] >From a0afc573ca47abe7f900a404d366599e5da93391 Mon Sep 17 00:00:00 2001 From: Andrew Cooper <andrew.cooper3@citrix.com> Date: Tue, 14 Jul 2015 16:58:49 +0100 Subject: [PATCH] x86/traps: Dump instruction stream in show_execution_state() For first pass triage of crashes, it is useful to have the instruction stream present, especially now that Xen binary patches itself. A sample output now looks like: (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82d0801607e4>] default_idle+0x76/0x7b (XEN) RFLAGS: 0000000000000246 CONTEXT: hypervisor (XEN) rax: ffff82d080331030 rbx: ffff83007fce8000 rcx: 0000000000000000 (XEN) rdx: 0000000000000000 rsi: ffff82d080331b98 rdi: 0000000000000000 (XEN) rbp: ffff83007fcefef0 rsp: ffff83007fcefef0 r8: ffff83007faf8118 (XEN) r9: 00000009983e89fd r10: 00000009983e89fd r11: 0000000000000246 (XEN) r12: ffff83007fd61000 r13: 00000000ffffffff r14: ffff83007fad9000 (XEN) r15: ffff83007fae3000 cr0: 000000008005003b cr4: 00000000000026e0 (XEN) cr3: 000000007fc9b000 cr2: 00007f70976b3fed (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) Xen code around e008:ffff82d0801607e4 (default_idle+0x76/0x7b): (XEN) 83 3c 10 00 75 04 fb f4 <eb> 01 fb 5d c3 55 48 89 e5 3b 3d 0d 50 12 00 72 (XEN) Xen stack trace from rsp=ffff83007fcefef0: (XEN) ffff83007fceff10 ffff82d080160e08 ffff82d08012c40a ffff83007faf9000 (XEN) ffff83007fcefdd8 ffffffff81a01fd8 ffff88002f07d4c0 ffffffff81a01fd8 (XEN) 0000000000000000 ffffffff81a01e58 ffffffff81a01fd8 0000000000000246 (XEN) 00000000ffff0052 0000000000000000 0000000000000000 0000000000000000 (XEN) ffffffff810013aa 0000000000000001 00000000deadbeef 00000000deadbeef (XEN) 0000010000000000 ffffffff810013aa 000000000000e033 0000000000000246 (XEN) ffffffff81a01e40 000000000000e02b 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff83007faf9000 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<ffff82d0801607e4>] default_idle+0x76/0x7b (XEN) [<ffff82d080160e08>] idle_loop+0x51/0x6e (XEN) Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <JBeulich@suse.com> --- Currently limited to just hypervisor context, but it could be extended to vcpus as well. --- xen/arch/x86/traps.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index e21fb78..658e0d7 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -114,6 +114,31 @@ boolean_param("ler", opt_ler); #define stack_words_per_line 4 #define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)regs->rsp) +static void show_code(const struct cpu_user_regs *regs) +{ + char insns[24]; + unsigned int i, not_copied; + void *__user start_ip = (void *)regs->rip - 8; + + if ( guest_mode(regs) ) + return; + + not_copied = __copy_from_user(insns, start_ip, ARRAY_SIZE(insns)); + + printk("Xen code around %04x:%p (%ps)%s:\n", + regs->cs, _p(regs->rip), _p(regs->rip), + !!not_copied ? " [fault on access]" : ""); + + for ( i = 0; i < ARRAY_SIZE(insns) - not_copied; ++i ) + { + if ( (unsigned long)(start_ip + i) == regs->rip ) + printk(" <%02x>", (unsigned char)insns[i]); + else + printk(" %02x", (unsigned char)insns[i]); + } + printk("\n"); +} + static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs) { int i; @@ -417,6 +442,7 @@ void show_stack_overflow(unsigned int cpu, const struct cpu_user_regs *regs) void show_execution_state(const struct cpu_user_regs *regs) { show_registers(regs); + show_code(regs); show_stack(regs); } -- 2.1.4 [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-13 10:09 ` Andrew Cooper @ 2015-11-14 0:16 ` Atom2 2015-11-14 20:32 ` Andrew Cooper 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-14 0:16 UTC (permalink / raw) To: Andrew Cooper; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 8466 bytes --] Am 13.11.15 um 11:09 schrieb Andrew Cooper: > On 13/11/15 07:25, Jan Beulich wrote: >>>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>> On 12/11/15 14:29, Atom2 wrote: >>>>> Hi Andrew, >>>>> thanks for your reply. Answers are inline further down. >>>>> >>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>>> of the >>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>> >>>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>>> domU which is started as part of the machine booting up: >>>>>>>> [...] >>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>> state (0). >>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>> (XEN) *** Guest State *** >>>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>>> gh_mask=ffffffffffffffff >>>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>>> gh_mask=ffffffffffffffff >>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>> odd? That will be the source of the failure. >>>>>> >>>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>>> should not be possible to set any of them. >>>>>> >>>>>> I suspect that the guest has exited for emulation, and there has been a >>>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>>> that there is a hardware errata which allows the guest to accidentally >>>>>> get it self into this condition. >>>>>> >>>>>> Are you able to rerun with a debug build of the hypervisor? >>>>> [snip] >>>>> Another question is whether prior to enabling the debug USE flag it >>>>> might make sense to re-compile with gcc-4.8.5 (please see my previous >>>>> list reply) to rule out any compiler related issues. Jan, Andrew - >>>>> what are your thoughts? >>>> First of all, check whether the compiler makes a difference on 4.5.2 >>> Hi Andrew, >>> I changed the compiler and there was no change to the better: >>> Unfortunately the HVM domU is still crashing with a similar error >>> message as soon as it is being started. >>>> If both compiles result in a guest crashing in that manner, test a debug >>>> Xen to see if any assertions/errors are encountered just before the >>>> guest crashes. >>>> >>> As the compiler did not make any difference, I enabled the debug USE >>> flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console >>> to capture output. Unfortunately I did not get very far and things >>> become even stranger: This time the system did not even finnish the boot >>> process, but rather hard-stopped pretty early with a message reading >>> "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile >>> is attached as "serial log.txt". >>> >>> As this happened immediately after the CPU microcode update, I thought >>> there might be a connection and disabled the microcode update. After the >>> next reboot it seemed as if the boot process got a bit further as >>> evidenced by a few more lines in the log file (those between lines 136 >>> and 197 in the second log file named "serial log no ucode.txt"), but in >>> the end it finnished off with an identical error message (only the CPU # >>> was different this time, but that number seems to change between boots >>> anyways). >>> >>> I hope that makes some sense to you. >> Not really, other than now even more suspecting bad hardware or >> something fundamentally wrong with your build. Did you retry with >> a freshly built 4.5.1? Could you alternatively try with a known good >> build of 4.5.2 (e.g. from osstest)? Andrew, many thanks again for your help. > Agreed. Double faults indicate that the exception handing entry points > are not set up in an appropriate state. Something is definitely wrong > with either the compiled binary or the hardware. The hardware (it's a SandyBridge XEON processor with ECC RAM and Enterprise SATA disks) has worked for almost two years together with XEN and other than this issue there's also currently nothing strange (i.e. if I boot with a standard linux kernel, the system boots and works without any issues and is very stable and there are also no strange messages in /var/log/messages). > Several questions and lines of investigation: > > Is this straight Xen 4.5.1 and 2, or do Gentoo have their own patches on > top? By the looks of it there are only security patches, but no gentoo specific patches. > On repeated attempts, are the details of the double fault identical > (other than the cpu), or does it move around (i.e. always do_IRQ+0x15) It always seems to be do_IRQ+0x15 (I have made a number of boots), and more specifically it was always do_IRQ+0x15/0x64c. Timings varied, the CPU differed between boots and also the rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, and r8 values were diffent as were those for r15 and cr2 and the values next to valid stack range. I don't know whether that's of relevance, but I thought I'd mention it after a quick analysis of two serial logs. > Can you boot with console_timestamps=boot on the command line in the > future. This will put Linux-sytle timestamps on log messages. Done - see two the attached serial log files mentioned above. > Can you also compile in the attached patch? I haven't quite got it > suitable for inclusion upstream yet, but it will also dump the > instruction stream under the fault. I have added the patch, but it seems not to trigger - at least the text that is in the patch does not show in the serial console output; it is however in the (uncompressed) xen.gz file as a quick grep for texts "Xen code around " and " [fault on access]" confirmed (grep said: binary file matches). > Finally, can you disassemble the xen-syms which results from the debug > build and paste the start of do_IRQ. (i.e. `gdb xen-syms` and "disass > do_IRQ") Please see the third file named "do_IRQ". Furthermore I have managed to get the system to again boot up (a HVM domU, however, still crashes): If I turn off the debug USE flag and just add symbols to the XEN binary. It seems that the debug USE flag is probably not what I was expecting. On https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces it describes the purpose of the debug USE flag as follows (emphasis by me): ==== start excerpt from web page ==== Some ebuilds provide a *debug* USE flag. While some mistakenly use it to provide debug information and play with compiler flags when it is enabled, that is not its purpose. _If you're trying to debug a reproduceable crash, you want to leave this USE flag alone, as it'll be building a different source than what you had before._ It is more efficient to get first a backtrace without changing the code, by simply emitting symbol information, and just afterward enable debug features to track the issue further down. Debug features that are enabled by the USE flag include assertions, debug logs on screen, debug files, leak detection and extra-safe operations (such as scrubbing memory before use). Some of them might be taxing, especially for complex software or software where performance is an important issue. For these reasons, please exercise caution when enabling the *debug* USE flag, and only consider it a last-chance card. ==== end excerpt from web page ==== Now _without_ the debug USE flag, but with debug information in the binary (I used splitdebug), all is back to where the problem started off (i.e. the system boots without issues until such time it starts a HVM domU which then crashes; PV domUs are working). I have attached the latest "xl dmesg" output with the timing information included. I hope any of this makes sense to you. Again many thanks and best regards Atom2 [-- Attachment #1.2: Type: text/html, Size: 10872 bytes --] [-- Attachment #2: serial log.1 --] [-- Type: text/plain, Size: 15103 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Fri Nov 13 23:16:55 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.505109] Detected 2394.658 MHz processor. (XEN) [ 1.512873] Initing memory sharing. (XEN) [ 1.517204] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.524119] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.534311] Intel machine check reporting enabled (XEN) [ 1.539858] alt table ffff82d0802e8810 -> ffff82d0802e9830 (XEN) [ 1.546192] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.554776] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.560847] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.567340] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.573578] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.579812] Intel VT-d Snoop Control not enabled. (XEN) [ 1.585450] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.591597] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.597316] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.603117] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.617545] I/O virtualisation enabled (XEN) [ 1.622124] - Dom0 mode: Relaxed (XEN) [ 1.626281] Interrupt remapping enabled (XEN) [ 1.631100] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.637548] ENABLING IO-APIC IRQs (XEN) [ 1.641695] -> Using old ACK method (XEN) [ 1.646648] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.855100] TSC deadline timer enabled (XEN) [ 2.242768] Platform timer is 14.318MHz HPET (XEN) [ 2.247566] 'A' pressed -> using alternative key handling (XEN) [ 2.248263] Allocated console ring of 64 KiB. (XEN) [ 2.249448] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.250472] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.251025] mwait-idle: v0.4 model 0x2a (XEN) [ 2.251543] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.252078] VMX: Supported advanced features: (XEN) [ 2.252630] - APIC MMIO access virtualisation (XEN) [ 2.253152] - APIC TPR shadow (XEN) [ 2.253665] - Extended Page Tables (EPT) (XEN) [ 2.254214] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.254958] - Virtual NMI (XEN) [ 2.255469] - MSR direct-access bitmap (XEN) [ 2.256018] - Unrestricted Guest (XEN) [ 2.256526] HVM: ASIDs enabled. (XEN) [ 2.257032] HVM: VMX enabled (XEN) [ 2.257571] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.258088] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.259248] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.260758] microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.262399] microcode: CPU6 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.263420] Brought up 8 CPUs (XEN) [ 2.269882] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.290536] ACPI sleep modes: S3 (XEN) [ 2.291042] mcheck_poll: Machine check polling timer started. (XEN) [ 2.291574] Dom0 has maximum 792 PIRQs (XEN) [ 2.292172] *** LOADING DOMAIN 0 *** (XEN) [ 2.475265] elf_parse_binary: phdr: paddr=0x1000000 memsz=0x65033b (XEN) [ 2.475826] elf_parse_binary: phdr: paddr=0x1651000 memsz=0x1e5000 (XEN) [ 2.476350] elf_parse_binary: phdr: paddr=0x1836000 memsz=0x98000 (XEN) [ 2.476874] elf_parse_binary: phdr: paddr=0x18ce000 memsz=0x1000 (XEN) [ 2.477431] elf_parse_binary: phdr: paddr=0x18cf000 memsz=0x13c98 (XEN) [ 2.477954] elf_parse_binary: phdr: paddr=0x18e3000 memsz=0x3d000 (XEN) [ 2.478477] elf_parse_binary: phdr: paddr=0x1920000 memsz=0x1120 (XEN) [ 2.479254] elf_parse_binary: phdr: paddr=0x1922000 memsz=0x2de000 (XEN) [ 2.479778] elf_parse_binary: memory: 0x1000000 -> 0x1c00000 (XEN) [ 2.480304] elf_xen_parse_note: GUEST_OS = "linux" (XEN) [ 2.480856] elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) [ 2.481374] elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) [ 2.481891] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) [ 2.482447] elf_xen_parse_note: ENTRY = 0xffffffff818e31f0 (XEN) [ 2.482967] elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) [ 2.483494] elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" (XEN) [ 2.485067] elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d (XEN) [ 2.485587] elf_xen_parse_note: PAE_MODE = "yes" (XEN) [ 2.486102] elf_xen_parse_note: LOADER = "generic" (XEN) [ 2.486652] elf_xen_parse_note: unknown xen elf note (0xd) (XEN) [ 2.487172] elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) [ 2.487688] elf_xen_parse_note: MOD_START_PFN = 0x1 (XEN) [ 2.488239] elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) [ 2.488761] elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) [ 2.489277] elf_xen_addr_calc_check: addresses: (XEN) [ 2.489825] virt_base = 0xffffffff80000000 (XEN) [ 2.490342] elf_paddr_offset = 0x0 (XEN) [ 2.490849] virt_offset = 0xffffffff80000000 (XEN) [ 2.491401] virt_kstart = 0xffffffff81000000 (XEN) [ 2.491917] virt_kend = 0xffffffff81c00000 (XEN) [ 2.492433] virt_entry = 0xffffffff818e31f0 (XEN) [ 2.492983] p2m_base = 0xffffffffffffffff (XEN) [ 2.493498] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 2.494011] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 2.495485] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 2.495994] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 2.497017] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 2.497576] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 2.498084] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 2.498605] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 2.499125] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 2.499647] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 2.500168] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 2.500689] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 2.501210] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 2.501767] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 2.503127] Dom0 has maximum 8 VCPUs (XEN) [ 2.503677] elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8165033b (XEN) [ 2.506063] elf_load_binary: phdr 1 at 0xffffffff81651000 -> 0xffffffff81836000 (XEN) [ 2.507497] elf_load_binary: phdr 2 at 0xffffffff81836000 -> 0xffffffff818ce000 (XEN) [ 2.508631] elf_load_binary: phdr 3 at 0xffffffff818ce000 -> 0xffffffff818cf000 (XEN) [ 2.509679] elf_load_binary: phdr 4 at 0xffffffff818cf000 -> 0xffffffff818e2c98 (XEN) [ 2.510709] elf_load_binary: phdr 5 at 0xffffffff818e3000 -> 0xffffffff81920000 (XEN) [ 2.512031] elf_load_binary: phdr 6 at 0xffffffff81920000 -> 0xffffffff81921120 (XEN) [ 2.513044] elf_load_binary: phdr 7 at 0xffffffff81922000 -> 0xffffffff819dd000 (XEN) [ 2.837080] *** DOUBLE FAULT *** (XEN) [ 2.841145] ----[ Xen-4.5.2 x86_64 debug=y Not tainted ]---- (XEN) [ 2.848113] CPU: 2 (XEN) [ 2.851223] RIP: e008:[<ffff82d08017658c>] do_IRQ+0x15/0x64c (XEN) [ 2.857979] RFLAGS: 0000000000010083 CONTEXT: hypervisor (XEN) [ 2.864508] rax: 000000378c73ed00 rbx: 0000000000000002 rcx: 0000000000196bd0 (XEN) [ 2.873177] rdx: 000000000006139c rsi: 00000000960b58b0 rdi: ffff83080caa6d38 (XEN) [ 2.881945] rbp: ffff83080caa6d28 rsp: ffff83080caa5ca8 r8: ffff82d080339380 (XEN) [ 2.890615] r9: 00000000000001c8 r10: 0000000000000001 r11: 0080000000000000 (XEN) [ 2.899355] r12: ffff82d08028a3c0 r13: 0000000000000001 r14: 0000000000000002 (XEN) [ 2.908026] r15: ffff83080ca9d060 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) [ 2.916765] cr3: 00000000db69f000 cr2: ffff83080caa5c98 (XEN) [ 2.923002] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) [ 2.931229] Valid stack range: ffff83080caa6000-ffff83080caa8000, sp=ffff83080caa5ca8, tss.esp0=ffff83080caa7fc0 (XEN) [ 2.942600] No stack overflow detected. Skipping stack trace. (XEN) [ 2.949239] (XEN) [ 2.951569] **************************************** (XEN) [ 2.957368] Panic on CPU 2: (XEN) [ 2.961094] DOUBLE FAULT -- system shutdown (XEN) [ 2.966116] **************************************** (XEN) [ 2.971914] (XEN) [ 2.974240] Reboot in five seconds... [-- Attachment #3: serial log.2 --] [-- Type: text/plain, Size: 15103 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Fri Nov 13 23:16:55 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.510160] Detected 2394.628 MHz processor. (XEN) [ 1.518149] Initing memory sharing. (XEN) [ 1.522479] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.529324] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.539399] Intel machine check reporting enabled (XEN) [ 1.544940] alt table ffff82d0802e8810 -> ffff82d0802e9830 (XEN) [ 1.551341] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.559830] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.565961] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.572376] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.578611] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.584910] Intel VT-d Snoop Control not enabled. (XEN) [ 1.590453] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.596818] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.602537] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.608250] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.622561] I/O virtualisation enabled (XEN) [ 1.627142] - Dom0 mode: Relaxed (XEN) [ 1.631406] Interrupt remapping enabled (XEN) [ 1.636080] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.642525] ENABLING IO-APIC IRQs (XEN) [ 1.646783] -> Using old ACK method (XEN) [ 1.651524] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.860153] TSC deadline timer enabled (XEN) [ 2.776868] Platform timer is 14.318MHz HPET (XEN) [ 2.781738] 'A' pressed -> using alternative key handling (XEN) [ 2.782434] Allocated console ring of 64 KiB. (XEN) [ 2.783614] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.784639] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.785192] mwait-idle: v0.4 model 0x2a (XEN) [ 2.785711] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.786249] VMX: Supported advanced features: (XEN) [ 2.786800] - APIC MMIO access virtualisation (XEN) [ 2.787323] - APIC TPR shadow (XEN) [ 2.787835] - Extended Page Tables (EPT) (XEN) [ 2.788383] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.788906] - Virtual NMI (XEN) [ 2.789418] - MSR direct-access bitmap (XEN) [ 2.789966] - Unrestricted Guest (XEN) [ 2.790473] HVM: ASIDs enabled. (XEN) [ 2.790979] HVM: VMX enabled (XEN) [ 2.791518] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.792036] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.793194] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.794705] microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.796347] microcode: CPU6 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.797562] Brought up 8 CPUs (XEN) [ 2.804020] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.824673] ACPI sleep modes: S3 (XEN) [ 2.825181] mcheck_poll: Machine check polling timer started. (XEN) [ 2.825713] Dom0 has maximum 792 PIRQs (XEN) [ 2.826310] *** LOADING DOMAIN 0 *** (XEN) [ 3.009539] elf_parse_binary: phdr: paddr=0x1000000 memsz=0x65033b (XEN) [ 3.010100] elf_parse_binary: phdr: paddr=0x1651000 memsz=0x1e5000 (XEN) [ 3.010625] elf_parse_binary: phdr: paddr=0x1836000 memsz=0x98000 (XEN) [ 3.011148] elf_parse_binary: phdr: paddr=0x18ce000 memsz=0x1000 (XEN) [ 3.011706] elf_parse_binary: phdr: paddr=0x18cf000 memsz=0x13c98 (XEN) [ 3.012228] elf_parse_binary: phdr: paddr=0x18e3000 memsz=0x3d000 (XEN) [ 3.012751] elf_parse_binary: phdr: paddr=0x1920000 memsz=0x1120 (XEN) [ 3.013310] elf_parse_binary: phdr: paddr=0x1922000 memsz=0x2de000 (XEN) [ 3.013832] elf_parse_binary: memory: 0x1000000 -> 0x1c00000 (XEN) [ 3.014358] elf_xen_parse_note: GUEST_OS = "linux" (XEN) [ 3.014910] elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) [ 3.015425] elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) [ 3.015941] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) [ 3.016500] elf_xen_parse_note: ENTRY = 0xffffffff818e31f0 (XEN) [ 3.017021] elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) [ 3.017548] elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" (XEN) [ 3.019122] elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d (XEN) [ 3.019642] elf_xen_parse_note: PAE_MODE = "yes" (XEN) [ 3.020155] elf_xen_parse_note: LOADER = "generic" (XEN) [ 3.020706] elf_xen_parse_note: unknown xen elf note (0xd) (XEN) [ 3.021443] elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) [ 3.021960] elf_xen_parse_note: MOD_START_PFN = 0x1 (XEN) [ 3.022509] elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) [ 3.023032] elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) [ 3.023548] elf_xen_addr_calc_check: addresses: (XEN) [ 3.024095] virt_base = 0xffffffff80000000 (XEN) [ 3.024611] elf_paddr_offset = 0x0 (XEN) [ 3.025119] virt_offset = 0xffffffff80000000 (XEN) [ 3.025671] virt_kstart = 0xffffffff81000000 (XEN) [ 3.026187] virt_kend = 0xffffffff81c00000 (XEN) [ 3.026702] virt_entry = 0xffffffff818e31f0 (XEN) [ 3.027254] p2m_base = 0xffffffffffffffff (XEN) [ 3.027771] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 3.028285] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 3.029543] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 3.030052] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 3.031073] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 3.031634] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 3.032143] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 3.032664] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 3.033185] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 3.033706] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 3.034227] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 3.034748] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 3.035269] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 3.035826] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 3.037405] Dom0 has maximum 8 VCPUs (XEN) [ 3.037953] elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8165033b (XEN) [ 3.040345] elf_load_binary: phdr 1 at 0xffffffff81651000 -> 0xffffffff81836000 (XEN) [ 3.041778] elf_load_binary: phdr 2 at 0xffffffff81836000 -> 0xffffffff818ce000 (XEN) [ 3.042915] elf_load_binary: phdr 3 at 0xffffffff818ce000 -> 0xffffffff818cf000 (XEN) [ 3.043966] elf_load_binary: phdr 4 at 0xffffffff818cf000 -> 0xffffffff818e2c98 (XEN) [ 3.044995] elf_load_binary: phdr 5 at 0xffffffff818e3000 -> 0xffffffff81920000 (XEN) [ 3.046091] elf_load_binary: phdr 6 at 0xffffffff81920000 -> 0xffffffff81921120 (XEN) [ 3.047106] elf_load_binary: phdr 7 at 0xffffffff81922000 -> 0xffffffff819dd000 (XEN) [ 3.371151] *** DOUBLE FAULT *** (XEN) [ 3.375352] ----[ Xen-4.5.2 x86_64 debug=y Not tainted ]---- (XEN) [ 3.382116] CPU: 4 (XEN) [ 3.385231] RIP: e008:[<ffff82d08017658c>] do_IRQ+0x15/0x64c (XEN) [ 3.392055] RFLAGS: 0000000000010083 CONTEXT: hypervisor (XEN) [ 3.398387] rax: ffff82d08011f917 rbx: 0000000000000004 rcx: 0000000000000004 (XEN) [ 3.407116] rdx: 000000378c756d00 rsi: 0000000000000004 rdi: ffff83080ca86d58 (XEN) [ 3.415790] rbp: ffff83080ca86d48 rsp: ffff83080ca85cc8 r8: 0000000000000004 (XEN) [ 3.424587] r9: 00000000000001c8 r10: 0000000000000001 r11: 0080000000000000 (XEN) [ 3.433259] r12: ffff82d08028a3c0 r13: 0000000000000001 r14: 0000000000000002 (XEN) [ 3.442047] r15: ffff83080ca9a060 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) [ 3.450727] cr3: 00000000db69f000 cr2: ffff83080ca85cb8 (XEN) [ 3.457090] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) [ 3.465244] Valid stack range: ffff83080ca86000-ffff83080ca88000, sp=ffff83080ca85cc8, tss.esp0=ffff83080ca87fc0 (XEN) [ 3.476670] No stack overflow detected. Skipping stack trace. (XEN) [ 3.483255] (XEN) [ 3.485792] **************************************** (XEN) [ 3.491595] Panic on CPU 4: (XEN) [ 3.495225] DOUBLE FAULT -- system shutdown (XEN) [ 3.500249] **************************************** (XEN) [ 3.506149] (XEN) [ 3.508477] Reboot in five seconds... [-- Attachment #4: do_IRQ --] [-- Type: text/plain, Size: 40367 bytes --] Dump of assembler code for function do_IRQ: 0xffff82d080176577 <+0>: add %al,(%rax) 0xffff82d080176579 <+2>: add %al,(%rax) 0xffff82d08017657b <+4>: add %al,(%rax) 0xffff82d08017657d <+6>: add %al,(%rax) 0xffff82d08017657f <+8>: add %al,(%rax) 0xffff82d080176581 <+10>: add %al,(%rax) 0xffff82d080176583 <+12>: add %al,(%rax) 0xffff82d080176585 <+14>: add %al,(%rax) 0xffff82d080176587 <+16>: add %al,(%rax) 0xffff82d080176589 <+18>: add %al,(%rax) 0xffff82d08017658b <+20>: add %al,(%rax) 0xffff82d08017658d <+22>: add %al,(%rax) 0xffff82d08017658f <+24>: add %al,(%rax) 0xffff82d080176591 <+26>: add %al,(%rax) 0xffff82d080176593 <+28>: add %al,(%rax) 0xffff82d080176595 <+30>: add %al,(%rax) 0xffff82d080176597 <+32>: add %al,(%rax) 0xffff82d080176599 <+34>: add %al,(%rax) 0xffff82d08017659b <+36>: add %al,(%rax) 0xffff82d08017659d <+38>: add %al,(%rax) 0xffff82d08017659f <+40>: add %al,(%rax) 0xffff82d0801765a1 <+42>: add %al,(%rax) 0xffff82d0801765a3 <+44>: add %al,(%rax) 0xffff82d0801765a5 <+46>: add %al,(%rax) 0xffff82d0801765a7 <+48>: add %al,(%rax) 0xffff82d0801765a9 <+50>: add %al,(%rax) 0xffff82d0801765ab <+52>: add %al,(%rax) 0xffff82d0801765ad <+54>: add %al,(%rax) 0xffff82d0801765af <+56>: add %al,(%rax) 0xffff82d0801765b1 <+58>: add %al,(%rax) 0xffff82d0801765b3 <+60>: add %al,(%rax) 0xffff82d0801765b5 <+62>: add %al,(%rax) 0xffff82d0801765b7 <+64>: add %al,(%rax) 0xffff82d0801765b9 <+66>: add %al,(%rax) 0xffff82d0801765bb <+68>: add %al,(%rax) 0xffff82d0801765bd <+70>: add %al,(%rax) 0xffff82d0801765bf <+72>: add %al,(%rax) 0xffff82d0801765c1 <+74>: add %al,(%rax) 0xffff82d0801765c3 <+76>: add %al,(%rax) 0xffff82d0801765c5 <+78>: add %al,(%rax) 0xffff82d0801765c7 <+80>: add %al,(%rax) 0xffff82d0801765c9 <+82>: add %al,(%rax) 0xffff82d0801765cb <+84>: add %al,(%rax) 0xffff82d0801765cd <+86>: add %al,(%rax) 0xffff82d0801765cf <+88>: add %al,(%rax) 0xffff82d0801765d1 <+90>: add %al,(%rax) 0xffff82d0801765d3 <+92>: add %al,(%rax) 0xffff82d0801765d5 <+94>: add %al,(%rax) 0xffff82d0801765d7 <+96>: add %al,(%rax) 0xffff82d0801765d9 <+98>: add %al,(%rax) 0xffff82d0801765db <+100>: add %al,(%rax) 0xffff82d0801765dd <+102>: add %al,(%rax) 0xffff82d0801765df <+104>: add %al,(%rax) 0xffff82d0801765e1 <+106>: add %al,(%rax) 0xffff82d0801765e3 <+108>: add %al,(%rax) 0xffff82d0801765e5 <+110>: add %al,(%rax) 0xffff82d0801765e7 <+112>: add %al,(%rax) 0xffff82d0801765e9 <+114>: add %al,(%rax) 0xffff82d0801765eb <+116>: add %al,(%rax) 0xffff82d0801765ed <+118>: add %al,(%rax) 0xffff82d0801765ef <+120>: add %al,(%rax) 0xffff82d0801765f1 <+122>: add %al,(%rax) 0xffff82d0801765f3 <+124>: add %al,(%rax) 0xffff82d0801765f5 <+126>: add %al,(%rax) 0xffff82d0801765f7 <+128>: add %al,(%rax) 0xffff82d0801765f9 <+130>: add %al,(%rax) 0xffff82d0801765fb <+132>: add %al,(%rax) 0xffff82d0801765fd <+134>: add %al,(%rax) 0xffff82d0801765ff <+136>: add %al,(%rax) 0xffff82d080176601 <+138>: add %al,(%rax) 0xffff82d080176603 <+140>: add %al,(%rax) 0xffff82d080176605 <+142>: add %al,(%rax) 0xffff82d080176607 <+144>: add %al,(%rax) 0xffff82d080176609 <+146>: add %al,(%rax) 0xffff82d08017660b <+148>: add %al,(%rax) 0xffff82d08017660d <+150>: add %al,(%rax) 0xffff82d08017660f <+152>: add %al,(%rax) 0xffff82d080176611 <+154>: add %al,(%rax) 0xffff82d080176613 <+156>: add %al,(%rax) 0xffff82d080176615 <+158>: add %al,(%rax) 0xffff82d080176617 <+160>: add %al,(%rax) 0xffff82d080176619 <+162>: add %al,(%rax) 0xffff82d08017661b <+164>: add %al,(%rax) 0xffff82d08017661d <+166>: add %al,(%rax) 0xffff82d08017661f <+168>: add %al,(%rax) 0xffff82d080176621 <+170>: add %al,(%rax) 0xffff82d080176623 <+172>: add %al,(%rax) 0xffff82d080176625 <+174>: add %al,(%rax) 0xffff82d080176627 <+176>: add %al,(%rax) 0xffff82d080176629 <+178>: add %al,(%rax) 0xffff82d08017662b <+180>: add %al,(%rax) 0xffff82d08017662d <+182>: add %al,(%rax) 0xffff82d08017662f <+184>: add %al,(%rax) 0xffff82d080176631 <+186>: add %al,(%rax) 0xffff82d080176633 <+188>: add %al,(%rax) 0xffff82d080176635 <+190>: add %al,(%rax) 0xffff82d080176637 <+192>: add %al,(%rax) 0xffff82d080176639 <+194>: add %al,(%rax) 0xffff82d08017663b <+196>: add %al,(%rax) 0xffff82d08017663d <+198>: add %al,(%rax) 0xffff82d08017663f <+200>: add %al,(%rax) 0xffff82d080176641 <+202>: add %al,(%rax) 0xffff82d080176643 <+204>: add %al,(%rax) 0xffff82d080176645 <+206>: add %al,(%rax) 0xffff82d080176647 <+208>: add %al,(%rax) 0xffff82d080176649 <+210>: add %al,(%rax) 0xffff82d08017664b <+212>: add %al,(%rax) 0xffff82d08017664d <+214>: add %al,(%rax) 0xffff82d08017664f <+216>: add %al,(%rax) 0xffff82d080176651 <+218>: add %al,(%rax) 0xffff82d080176653 <+220>: add %al,(%rax) 0xffff82d080176655 <+222>: add %al,(%rax) 0xffff82d080176657 <+224>: add %al,(%rax) 0xffff82d080176659 <+226>: add %al,(%rax) 0xffff82d08017665b <+228>: add %al,(%rax) 0xffff82d08017665d <+230>: add %al,(%rax) 0xffff82d08017665f <+232>: add %al,(%rax) 0xffff82d080176661 <+234>: add %al,(%rax) 0xffff82d080176663 <+236>: add %al,(%rax) 0xffff82d080176665 <+238>: add %al,(%rax) 0xffff82d080176667 <+240>: add %al,(%rax) 0xffff82d080176669 <+242>: add %al,(%rax) 0xffff82d08017666b <+244>: add %al,(%rax) 0xffff82d08017666d <+246>: add %al,(%rax) 0xffff82d08017666f <+248>: add %al,(%rax) 0xffff82d080176671 <+250>: add %al,(%rax) 0xffff82d080176673 <+252>: add %al,(%rax) 0xffff82d080176675 <+254>: add %al,(%rax) 0xffff82d080176677 <+256>: add %al,(%rax) 0xffff82d080176679 <+258>: add %al,(%rax) 0xffff82d08017667b <+260>: add %al,(%rax) 0xffff82d08017667d <+262>: add %al,(%rax) 0xffff82d08017667f <+264>: add %al,(%rax) 0xffff82d080176681 <+266>: add %al,(%rax) 0xffff82d080176683 <+268>: add %al,(%rax) 0xffff82d080176685 <+270>: add %al,(%rax) 0xffff82d080176687 <+272>: add %al,(%rax) 0xffff82d080176689 <+274>: add %al,(%rax) 0xffff82d08017668b <+276>: add %al,(%rax) 0xffff82d08017668d <+278>: add %al,(%rax) 0xffff82d08017668f <+280>: add %al,(%rax) 0xffff82d080176691 <+282>: add %al,(%rax) 0xffff82d080176693 <+284>: add %al,(%rax) 0xffff82d080176695 <+286>: add %al,(%rax) 0xffff82d080176697 <+288>: add %al,(%rax) 0xffff82d080176699 <+290>: add %al,(%rax) 0xffff82d08017669b <+292>: add %al,(%rax) 0xffff82d08017669d <+294>: add %al,(%rax) 0xffff82d08017669f <+296>: add %al,(%rax) 0xffff82d0801766a1 <+298>: add %al,(%rax) 0xffff82d0801766a3 <+300>: add %al,(%rax) 0xffff82d0801766a5 <+302>: add %al,(%rax) 0xffff82d0801766a7 <+304>: add %al,(%rax) 0xffff82d0801766a9 <+306>: add %al,(%rax) 0xffff82d0801766ab <+308>: add %al,(%rax) 0xffff82d0801766ad <+310>: add %al,(%rax) 0xffff82d0801766af <+312>: add %al,(%rax) 0xffff82d0801766b1 <+314>: add %al,(%rax) 0xffff82d0801766b3 <+316>: add %al,(%rax) 0xffff82d0801766b5 <+318>: add %al,(%rax) 0xffff82d0801766b7 <+320>: add %al,(%rax) 0xffff82d0801766b9 <+322>: add %al,(%rax) 0xffff82d0801766bb <+324>: add %al,(%rax) 0xffff82d0801766bd <+326>: add %al,(%rax) 0xffff82d0801766bf <+328>: add %al,(%rax) 0xffff82d0801766c1 <+330>: add %al,(%rax) 0xffff82d0801766c3 <+332>: add %al,(%rax) 0xffff82d0801766c5 <+334>: add %al,(%rax) 0xffff82d0801766c7 <+336>: add %al,(%rax) 0xffff82d0801766c9 <+338>: add %al,(%rax) 0xffff82d0801766cb <+340>: add %al,(%rax) 0xffff82d0801766cd <+342>: add %al,(%rax) 0xffff82d0801766cf <+344>: add %al,(%rax) 0xffff82d0801766d1 <+346>: add %al,(%rax) 0xffff82d0801766d3 <+348>: add %al,(%rax) 0xffff82d0801766d5 <+350>: add %al,(%rax) 0xffff82d0801766d7 <+352>: add %al,(%rax) 0xffff82d0801766d9 <+354>: add %al,(%rax) 0xffff82d0801766db <+356>: add %al,(%rax) 0xffff82d0801766dd <+358>: add %al,(%rax) 0xffff82d0801766df <+360>: add %al,(%rax) 0xffff82d0801766e1 <+362>: add %al,(%rax) 0xffff82d0801766e3 <+364>: add %al,(%rax) 0xffff82d0801766e5 <+366>: add %al,(%rax) 0xffff82d0801766e7 <+368>: add %al,(%rax) 0xffff82d0801766e9 <+370>: add %al,(%rax) 0xffff82d0801766eb <+372>: add %al,(%rax) 0xffff82d0801766ed <+374>: add %al,(%rax) 0xffff82d0801766ef <+376>: add %al,(%rax) 0xffff82d0801766f1 <+378>: add %al,(%rax) 0xffff82d0801766f3 <+380>: add %al,(%rax) 0xffff82d0801766f5 <+382>: add %al,(%rax) 0xffff82d0801766f7 <+384>: add %al,(%rax) 0xffff82d0801766f9 <+386>: add %al,(%rax) 0xffff82d0801766fb <+388>: add %al,(%rax) 0xffff82d0801766fd <+390>: add %al,(%rax) 0xffff82d0801766ff <+392>: add %al,(%rax) 0xffff82d080176701 <+394>: add %al,(%rax) 0xffff82d080176703 <+396>: add %al,(%rax) 0xffff82d080176705 <+398>: add %al,(%rax) 0xffff82d080176707 <+400>: add %al,(%rax) 0xffff82d080176709 <+402>: add %al,(%rax) 0xffff82d08017670b <+404>: add %al,(%rax) 0xffff82d08017670d <+406>: add %al,(%rax) 0xffff82d08017670f <+408>: add %al,(%rax) 0xffff82d080176711 <+410>: add %al,(%rax) 0xffff82d080176713 <+412>: add %al,(%rax) 0xffff82d080176715 <+414>: add %al,(%rax) 0xffff82d080176717 <+416>: add %al,(%rax) 0xffff82d080176719 <+418>: add %al,(%rax) 0xffff82d08017671b <+420>: add %al,(%rax) 0xffff82d08017671d <+422>: add %al,(%rax) 0xffff82d08017671f <+424>: add %al,(%rax) 0xffff82d080176721 <+426>: add %al,(%rax) 0xffff82d080176723 <+428>: add %al,(%rax) 0xffff82d080176725 <+430>: add %al,(%rax) 0xffff82d080176727 <+432>: add %al,(%rax) 0xffff82d080176729 <+434>: add %al,(%rax) 0xffff82d08017672b <+436>: add %al,(%rax) 0xffff82d08017672d <+438>: add %al,(%rax) 0xffff82d08017672f <+440>: add %al,(%rax) 0xffff82d080176731 <+442>: add %al,(%rax) 0xffff82d080176733 <+444>: add %al,(%rax) 0xffff82d080176735 <+446>: add %al,(%rax) 0xffff82d080176737 <+448>: add %al,(%rax) 0xffff82d080176739 <+450>: add %al,(%rax) 0xffff82d08017673b <+452>: add %al,(%rax) 0xffff82d08017673d <+454>: add %al,(%rax) 0xffff82d08017673f <+456>: add %al,(%rax) 0xffff82d080176741 <+458>: add %al,(%rax) 0xffff82d080176743 <+460>: add %al,(%rax) 0xffff82d080176745 <+462>: add %al,(%rax) 0xffff82d080176747 <+464>: add %al,(%rax) 0xffff82d080176749 <+466>: add %al,(%rax) 0xffff82d08017674b <+468>: add %al,(%rax) 0xffff82d08017674d <+470>: add %al,(%rax) 0xffff82d08017674f <+472>: add %al,(%rax) 0xffff82d080176751 <+474>: add %al,(%rax) 0xffff82d080176753 <+476>: add %al,(%rax) 0xffff82d080176755 <+478>: add %al,(%rax) 0xffff82d080176757 <+480>: add %al,(%rax) 0xffff82d080176759 <+482>: add %al,(%rax) 0xffff82d08017675b <+484>: add %al,(%rax) 0xffff82d08017675d <+486>: add %al,(%rax) 0xffff82d08017675f <+488>: add %al,(%rax) 0xffff82d080176761 <+490>: add %al,(%rax) 0xffff82d080176763 <+492>: add %al,(%rax) 0xffff82d080176765 <+494>: add %al,(%rax) 0xffff82d080176767 <+496>: add %al,(%rax) 0xffff82d080176769 <+498>: add %al,(%rax) 0xffff82d08017676b <+500>: add %al,(%rax) 0xffff82d08017676d <+502>: add %al,(%rax) 0xffff82d08017676f <+504>: add %al,(%rax) 0xffff82d080176771 <+506>: add %al,(%rax) 0xffff82d080176773 <+508>: add %al,(%rax) 0xffff82d080176775 <+510>: add %al,(%rax) 0xffff82d080176777 <+512>: add %al,(%rax) 0xffff82d080176779 <+514>: add %al,(%rax) 0xffff82d08017677b <+516>: add %al,(%rax) 0xffff82d08017677d <+518>: add %al,(%rax) 0xffff82d08017677f <+520>: add %al,(%rax) 0xffff82d080176781 <+522>: add %al,(%rax) 0xffff82d080176783 <+524>: add %al,(%rax) 0xffff82d080176785 <+526>: add %al,(%rax) 0xffff82d080176787 <+528>: add %al,(%rax) 0xffff82d080176789 <+530>: add %al,(%rax) 0xffff82d08017678b <+532>: add %al,(%rax) 0xffff82d08017678d <+534>: add %al,(%rax) 0xffff82d08017678f <+536>: add %al,(%rax) 0xffff82d080176791 <+538>: add %al,(%rax) 0xffff82d080176793 <+540>: add %al,(%rax) 0xffff82d080176795 <+542>: add %al,(%rax) 0xffff82d080176797 <+544>: add %al,(%rax) 0xffff82d080176799 <+546>: add %al,(%rax) 0xffff82d08017679b <+548>: add %al,(%rax) 0xffff82d08017679d <+550>: add %al,(%rax) 0xffff82d08017679f <+552>: add %al,(%rax) 0xffff82d0801767a1 <+554>: add %al,(%rax) 0xffff82d0801767a3 <+556>: add %al,(%rax) 0xffff82d0801767a5 <+558>: add %al,(%rax) 0xffff82d0801767a7 <+560>: add %al,(%rax) 0xffff82d0801767a9 <+562>: add %al,(%rax) 0xffff82d0801767ab <+564>: add %al,(%rax) 0xffff82d0801767ad <+566>: add %al,(%rax) 0xffff82d0801767af <+568>: add %al,(%rax) 0xffff82d0801767b1 <+570>: add %al,(%rax) 0xffff82d0801767b3 <+572>: add %al,(%rax) 0xffff82d0801767b5 <+574>: add %al,(%rax) 0xffff82d0801767b7 <+576>: add %al,(%rax) 0xffff82d0801767b9 <+578>: add %al,(%rax) 0xffff82d0801767bb <+580>: add %al,(%rax) 0xffff82d0801767bd <+582>: add %al,(%rax) 0xffff82d0801767bf <+584>: add %al,(%rax) 0xffff82d0801767c1 <+586>: add %al,(%rax) 0xffff82d0801767c3 <+588>: add %al,(%rax) 0xffff82d0801767c5 <+590>: add %al,(%rax) 0xffff82d0801767c7 <+592>: add %al,(%rax) 0xffff82d0801767c9 <+594>: add %al,(%rax) 0xffff82d0801767cb <+596>: add %al,(%rax) 0xffff82d0801767cd <+598>: add %al,(%rax) 0xffff82d0801767cf <+600>: add %al,(%rax) 0xffff82d0801767d1 <+602>: add %al,(%rax) 0xffff82d0801767d3 <+604>: add %al,(%rax) 0xffff82d0801767d5 <+606>: add %al,(%rax) 0xffff82d0801767d7 <+608>: add %al,(%rax) 0xffff82d0801767d9 <+610>: add %al,(%rax) 0xffff82d0801767db <+612>: add %al,(%rax) 0xffff82d0801767dd <+614>: add %al,(%rax) 0xffff82d0801767df <+616>: add %al,(%rax) 0xffff82d0801767e1 <+618>: add %al,(%rax) 0xffff82d0801767e3 <+620>: add %al,(%rax) 0xffff82d0801767e5 <+622>: add %al,(%rax) 0xffff82d0801767e7 <+624>: add %al,(%rax) 0xffff82d0801767e9 <+626>: add %al,(%rax) 0xffff82d0801767eb <+628>: add %al,(%rax) 0xffff82d0801767ed <+630>: add %al,(%rax) 0xffff82d0801767ef <+632>: add %al,(%rax) 0xffff82d0801767f1 <+634>: add %al,(%rax) 0xffff82d0801767f3 <+636>: add %al,(%rax) 0xffff82d0801767f5 <+638>: add %al,(%rax) 0xffff82d0801767f7 <+640>: add %al,(%rax) 0xffff82d0801767f9 <+642>: add %al,(%rax) 0xffff82d0801767fb <+644>: add %al,(%rax) 0xffff82d0801767fd <+646>: add %al,(%rax) 0xffff82d0801767ff <+648>: add %al,(%rax) 0xffff82d080176801 <+650>: add %al,(%rax) 0xffff82d080176803 <+652>: add %al,(%rax) 0xffff82d080176805 <+654>: add %al,(%rax) 0xffff82d080176807 <+656>: add %al,(%rax) 0xffff82d080176809 <+658>: add %al,(%rax) 0xffff82d08017680b <+660>: add %al,(%rax) 0xffff82d08017680d <+662>: add %al,(%rax) 0xffff82d08017680f <+664>: add %al,(%rax) 0xffff82d080176811 <+666>: add %al,(%rax) 0xffff82d080176813 <+668>: add %al,(%rax) 0xffff82d080176815 <+670>: add %al,(%rax) 0xffff82d080176817 <+672>: add %al,(%rax) 0xffff82d080176819 <+674>: add %al,(%rax) 0xffff82d08017681b <+676>: add %al,(%rax) 0xffff82d08017681d <+678>: add %al,(%rax) 0xffff82d08017681f <+680>: add %al,(%rax) 0xffff82d080176821 <+682>: add %al,(%rax) 0xffff82d080176823 <+684>: add %al,(%rax) 0xffff82d080176825 <+686>: add %al,(%rax) 0xffff82d080176827 <+688>: add %al,(%rax) 0xffff82d080176829 <+690>: add %al,(%rax) 0xffff82d08017682b <+692>: add %al,(%rax) 0xffff82d08017682d <+694>: add %al,(%rax) 0xffff82d08017682f <+696>: add %al,(%rax) 0xffff82d080176831 <+698>: add %al,(%rax) 0xffff82d080176833 <+700>: add %al,(%rax) 0xffff82d080176835 <+702>: add %al,(%rax) 0xffff82d080176837 <+704>: add %al,(%rax) 0xffff82d080176839 <+706>: add %al,(%rax) 0xffff82d08017683b <+708>: add %al,(%rax) 0xffff82d08017683d <+710>: add %al,(%rax) 0xffff82d08017683f <+712>: add %al,(%rax) 0xffff82d080176841 <+714>: add %al,(%rax) 0xffff82d080176843 <+716>: add %al,(%rax) 0xffff82d080176845 <+718>: add %al,(%rax) 0xffff82d080176847 <+720>: add %al,(%rax) 0xffff82d080176849 <+722>: add %al,(%rax) 0xffff82d08017684b <+724>: add %al,(%rax) 0xffff82d08017684d <+726>: add %al,(%rax) 0xffff82d08017684f <+728>: add %al,(%rax) 0xffff82d080176851 <+730>: add %al,(%rax) 0xffff82d080176853 <+732>: add %al,(%rax) 0xffff82d080176855 <+734>: add %al,(%rax) 0xffff82d080176857 <+736>: add %al,(%rax) 0xffff82d080176859 <+738>: add %al,(%rax) 0xffff82d08017685b <+740>: add %al,(%rax) 0xffff82d08017685d <+742>: add %al,(%rax) 0xffff82d08017685f <+744>: add %al,(%rax) 0xffff82d080176861 <+746>: add %al,(%rax) 0xffff82d080176863 <+748>: add %al,(%rax) 0xffff82d080176865 <+750>: add %al,(%rax) 0xffff82d080176867 <+752>: add %al,(%rax) 0xffff82d080176869 <+754>: add %al,(%rax) 0xffff82d08017686b <+756>: add %al,(%rax) 0xffff82d08017686d <+758>: add %al,(%rax) 0xffff82d08017686f <+760>: add %al,(%rax) 0xffff82d080176871 <+762>: add %al,(%rax) 0xffff82d080176873 <+764>: add %al,(%rax) 0xffff82d080176875 <+766>: add %al,(%rax) 0xffff82d080176877 <+768>: add %al,(%rax) 0xffff82d080176879 <+770>: add %al,(%rax) 0xffff82d08017687b <+772>: add %al,(%rax) 0xffff82d08017687d <+774>: add %al,(%rax) 0xffff82d08017687f <+776>: add %al,(%rax) 0xffff82d080176881 <+778>: add %al,(%rax) 0xffff82d080176883 <+780>: add %al,(%rax) 0xffff82d080176885 <+782>: add %al,(%rax) 0xffff82d080176887 <+784>: add %al,(%rax) 0xffff82d080176889 <+786>: add %al,(%rax) 0xffff82d08017688b <+788>: add %al,(%rax) 0xffff82d08017688d <+790>: add %al,(%rax) 0xffff82d08017688f <+792>: add %al,(%rax) 0xffff82d080176891 <+794>: add %al,(%rax) 0xffff82d080176893 <+796>: add %al,(%rax) 0xffff82d080176895 <+798>: add %al,(%rax) 0xffff82d080176897 <+800>: add %al,(%rax) 0xffff82d080176899 <+802>: add %al,(%rax) 0xffff82d08017689b <+804>: add %al,(%rax) 0xffff82d08017689d <+806>: add %al,(%rax) 0xffff82d08017689f <+808>: add %al,(%rax) 0xffff82d0801768a1 <+810>: add %al,(%rax) 0xffff82d0801768a3 <+812>: add %al,(%rax) 0xffff82d0801768a5 <+814>: add %al,(%rax) 0xffff82d0801768a7 <+816>: add %al,(%rax) 0xffff82d0801768a9 <+818>: add %al,(%rax) 0xffff82d0801768ab <+820>: add %al,(%rax) 0xffff82d0801768ad <+822>: add %al,(%rax) 0xffff82d0801768af <+824>: add %al,(%rax) 0xffff82d0801768b1 <+826>: add %al,(%rax) 0xffff82d0801768b3 <+828>: add %al,(%rax) 0xffff82d0801768b5 <+830>: add %al,(%rax) 0xffff82d0801768b7 <+832>: add %al,(%rax) 0xffff82d0801768b9 <+834>: add %al,(%rax) 0xffff82d0801768bb <+836>: add %al,(%rax) 0xffff82d0801768bd <+838>: add %al,(%rax) 0xffff82d0801768bf <+840>: add %al,(%rax) 0xffff82d0801768c1 <+842>: add %al,(%rax) 0xffff82d0801768c3 <+844>: add %al,(%rax) 0xffff82d0801768c5 <+846>: add %al,(%rax) 0xffff82d0801768c7 <+848>: add %al,(%rax) 0xffff82d0801768c9 <+850>: add %al,(%rax) 0xffff82d0801768cb <+852>: add %al,(%rax) 0xffff82d0801768cd <+854>: add %al,(%rax) 0xffff82d0801768cf <+856>: add %al,(%rax) 0xffff82d0801768d1 <+858>: add %al,(%rax) 0xffff82d0801768d3 <+860>: add %al,(%rax) 0xffff82d0801768d5 <+862>: add %al,(%rax) 0xffff82d0801768d7 <+864>: add %al,(%rax) 0xffff82d0801768d9 <+866>: add %al,(%rax) 0xffff82d0801768db <+868>: add %al,(%rax) 0xffff82d0801768dd <+870>: add %al,(%rax) 0xffff82d0801768df <+872>: add %al,(%rax) 0xffff82d0801768e1 <+874>: add %al,(%rax) 0xffff82d0801768e3 <+876>: add %al,(%rax) 0xffff82d0801768e5 <+878>: add %al,(%rax) 0xffff82d0801768e7 <+880>: add %al,(%rax) 0xffff82d0801768e9 <+882>: add %al,(%rax) 0xffff82d0801768eb <+884>: add %al,(%rax) 0xffff82d0801768ed <+886>: add %al,(%rax) 0xffff82d0801768ef <+888>: add %al,(%rax) 0xffff82d0801768f1 <+890>: add %al,(%rax) 0xffff82d0801768f3 <+892>: add %al,(%rax) 0xffff82d0801768f5 <+894>: add %al,(%rax) 0xffff82d0801768f7 <+896>: add %al,(%rax) 0xffff82d0801768f9 <+898>: add %al,(%rax) 0xffff82d0801768fb <+900>: add %al,(%rax) 0xffff82d0801768fd <+902>: add %al,(%rax) 0xffff82d0801768ff <+904>: add %al,(%rax) 0xffff82d080176901 <+906>: add %al,(%rax) 0xffff82d080176903 <+908>: add %al,(%rax) 0xffff82d080176905 <+910>: add %al,(%rax) 0xffff82d080176907 <+912>: add %al,(%rax) 0xffff82d080176909 <+914>: add %al,(%rax) 0xffff82d08017690b <+916>: add %al,(%rax) 0xffff82d08017690d <+918>: add %al,(%rax) 0xffff82d08017690f <+920>: add %al,(%rax) 0xffff82d080176911 <+922>: add %al,(%rax) 0xffff82d080176913 <+924>: add %al,(%rax) 0xffff82d080176915 <+926>: add %al,(%rax) 0xffff82d080176917 <+928>: add %al,(%rax) 0xffff82d080176919 <+930>: add %al,(%rax) 0xffff82d08017691b <+932>: add %al,(%rax) 0xffff82d08017691d <+934>: add %al,(%rax) 0xffff82d08017691f <+936>: add %al,(%rax) 0xffff82d080176921 <+938>: add %al,(%rax) 0xffff82d080176923 <+940>: add %al,(%rax) 0xffff82d080176925 <+942>: add %al,(%rax) 0xffff82d080176927 <+944>: add %al,(%rax) 0xffff82d080176929 <+946>: add %al,(%rax) 0xffff82d08017692b <+948>: add %al,(%rax) 0xffff82d08017692d <+950>: add %al,(%rax) 0xffff82d08017692f <+952>: add %al,(%rax) 0xffff82d080176931 <+954>: add %al,(%rax) 0xffff82d080176933 <+956>: add %al,(%rax) 0xffff82d080176935 <+958>: add %al,(%rax) 0xffff82d080176937 <+960>: add %al,(%rax) 0xffff82d080176939 <+962>: add %al,(%rax) 0xffff82d08017693b <+964>: add %al,(%rax) 0xffff82d08017693d <+966>: add %al,(%rax) 0xffff82d08017693f <+968>: add %al,(%rax) 0xffff82d080176941 <+970>: add %al,(%rax) 0xffff82d080176943 <+972>: add %al,(%rax) 0xffff82d080176945 <+974>: add %al,(%rax) 0xffff82d080176947 <+976>: add %al,(%rax) 0xffff82d080176949 <+978>: add %al,(%rax) 0xffff82d08017694b <+980>: add %al,(%rax) 0xffff82d08017694d <+982>: add %al,(%rax) 0xffff82d08017694f <+984>: add %al,(%rax) 0xffff82d080176951 <+986>: add %al,(%rax) 0xffff82d080176953 <+988>: add %al,(%rax) 0xffff82d080176955 <+990>: add %al,(%rax) 0xffff82d080176957 <+992>: add %al,(%rax) 0xffff82d080176959 <+994>: add %al,(%rax) 0xffff82d08017695b <+996>: add %al,(%rax) 0xffff82d08017695d <+998>: add %al,(%rax) 0xffff82d08017695f <+1000>: add %al,(%rax) 0xffff82d080176961 <+1002>: add %al,(%rax) 0xffff82d080176963 <+1004>: add %al,(%rax) 0xffff82d080176965 <+1006>: add %al,(%rax) 0xffff82d080176967 <+1008>: add %al,(%rax) 0xffff82d080176969 <+1010>: add %al,(%rax) 0xffff82d08017696b <+1012>: add %al,(%rax) 0xffff82d08017696d <+1014>: add %al,(%rax) 0xffff82d08017696f <+1016>: add %al,(%rax) 0xffff82d080176971 <+1018>: add %al,(%rax) 0xffff82d080176973 <+1020>: add %al,(%rax) 0xffff82d080176975 <+1022>: add %al,(%rax) 0xffff82d080176977 <+1024>: add %al,(%rax) 0xffff82d080176979 <+1026>: add %al,(%rax) 0xffff82d08017697b <+1028>: add %al,(%rax) 0xffff82d08017697d <+1030>: add %al,(%rax) 0xffff82d08017697f <+1032>: add %al,(%rax) 0xffff82d080176981 <+1034>: add %al,(%rax) 0xffff82d080176983 <+1036>: add %al,(%rax) 0xffff82d080176985 <+1038>: add %al,(%rax) 0xffff82d080176987 <+1040>: add %al,(%rax) 0xffff82d080176989 <+1042>: add %al,(%rax) 0xffff82d08017698b <+1044>: add %al,(%rax) 0xffff82d08017698d <+1046>: add %al,(%rax) 0xffff82d08017698f <+1048>: add %al,(%rax) 0xffff82d080176991 <+1050>: add %al,(%rax) 0xffff82d080176993 <+1052>: add %al,(%rax) 0xffff82d080176995 <+1054>: add %al,(%rax) 0xffff82d080176997 <+1056>: add %al,(%rax) 0xffff82d080176999 <+1058>: add %al,(%rax) 0xffff82d08017699b <+1060>: add %al,(%rax) 0xffff82d08017699d <+1062>: add %al,(%rax) 0xffff82d08017699f <+1064>: add %al,(%rax) 0xffff82d0801769a1 <+1066>: add %al,(%rax) 0xffff82d0801769a3 <+1068>: add %al,(%rax) 0xffff82d0801769a5 <+1070>: add %al,(%rax) 0xffff82d0801769a7 <+1072>: add %al,(%rax) 0xffff82d0801769a9 <+1074>: add %al,(%rax) 0xffff82d0801769ab <+1076>: add %al,(%rax) 0xffff82d0801769ad <+1078>: add %al,(%rax) 0xffff82d0801769af <+1080>: add %al,(%rax) 0xffff82d0801769b1 <+1082>: add %al,(%rax) 0xffff82d0801769b3 <+1084>: add %al,(%rax) 0xffff82d0801769b5 <+1086>: add %al,(%rax) 0xffff82d0801769b7 <+1088>: add %al,(%rax) 0xffff82d0801769b9 <+1090>: add %al,(%rax) 0xffff82d0801769bb <+1092>: add %al,(%rax) 0xffff82d0801769bd <+1094>: add %al,(%rax) 0xffff82d0801769bf <+1096>: add %al,(%rax) 0xffff82d0801769c1 <+1098>: add %al,(%rax) 0xffff82d0801769c3 <+1100>: add %al,(%rax) 0xffff82d0801769c5 <+1102>: add %al,(%rax) 0xffff82d0801769c7 <+1104>: add %al,(%rax) 0xffff82d0801769c9 <+1106>: add %al,(%rax) 0xffff82d0801769cb <+1108>: add %al,(%rax) 0xffff82d0801769cd <+1110>: add %al,(%rax) 0xffff82d0801769cf <+1112>: add %al,(%rax) 0xffff82d0801769d1 <+1114>: add %al,(%rax) 0xffff82d0801769d3 <+1116>: add %al,(%rax) 0xffff82d0801769d5 <+1118>: add %al,(%rax) 0xffff82d0801769d7 <+1120>: add %al,(%rax) 0xffff82d0801769d9 <+1122>: add %al,(%rax) 0xffff82d0801769db <+1124>: add %al,(%rax) 0xffff82d0801769dd <+1126>: add %al,(%rax) 0xffff82d0801769df <+1128>: add %al,(%rax) 0xffff82d0801769e1 <+1130>: add %al,(%rax) 0xffff82d0801769e3 <+1132>: add %al,(%rax) 0xffff82d0801769e5 <+1134>: add %al,(%rax) 0xffff82d0801769e7 <+1136>: add %al,(%rax) 0xffff82d0801769e9 <+1138>: add %al,(%rax) 0xffff82d0801769eb <+1140>: add %al,(%rax) 0xffff82d0801769ed <+1142>: add %al,(%rax) 0xffff82d0801769ef <+1144>: add %al,(%rax) 0xffff82d0801769f1 <+1146>: add %al,(%rax) 0xffff82d0801769f3 <+1148>: add %al,(%rax) 0xffff82d0801769f5 <+1150>: add %al,(%rax) 0xffff82d0801769f7 <+1152>: add %al,(%rax) 0xffff82d0801769f9 <+1154>: add %al,(%rax) 0xffff82d0801769fb <+1156>: add %al,(%rax) 0xffff82d0801769fd <+1158>: add %al,(%rax) 0xffff82d0801769ff <+1160>: add %al,(%rax) 0xffff82d080176a01 <+1162>: add %al,(%rax) 0xffff82d080176a03 <+1164>: add %al,(%rax) 0xffff82d080176a05 <+1166>: add %al,(%rax) 0xffff82d080176a07 <+1168>: add %al,(%rax) 0xffff82d080176a09 <+1170>: add %al,(%rax) 0xffff82d080176a0b <+1172>: add %al,(%rax) 0xffff82d080176a0d <+1174>: add %al,(%rax) 0xffff82d080176a0f <+1176>: add %al,(%rax) 0xffff82d080176a11 <+1178>: add %al,(%rax) 0xffff82d080176a13 <+1180>: add %al,(%rax) 0xffff82d080176a15 <+1182>: add %al,(%rax) 0xffff82d080176a17 <+1184>: add %al,(%rax) 0xffff82d080176a19 <+1186>: add %al,(%rax) 0xffff82d080176a1b <+1188>: add %al,(%rax) 0xffff82d080176a1d <+1190>: add %al,(%rax) 0xffff82d080176a1f <+1192>: add %al,(%rax) 0xffff82d080176a21 <+1194>: add %al,(%rax) 0xffff82d080176a23 <+1196>: add %al,(%rax) 0xffff82d080176a25 <+1198>: add %al,(%rax) 0xffff82d080176a27 <+1200>: add %al,(%rax) 0xffff82d080176a29 <+1202>: add %al,(%rax) 0xffff82d080176a2b <+1204>: add %al,(%rax) 0xffff82d080176a2d <+1206>: add %al,(%rax) 0xffff82d080176a2f <+1208>: add %al,(%rax) 0xffff82d080176a31 <+1210>: add %al,(%rax) 0xffff82d080176a33 <+1212>: add %al,(%rax) 0xffff82d080176a35 <+1214>: add %al,(%rax) 0xffff82d080176a37 <+1216>: add %al,(%rax) 0xffff82d080176a39 <+1218>: add %al,(%rax) 0xffff82d080176a3b <+1220>: add %al,(%rax) 0xffff82d080176a3d <+1222>: add %al,(%rax) 0xffff82d080176a3f <+1224>: add %al,(%rax) 0xffff82d080176a41 <+1226>: add %al,(%rax) 0xffff82d080176a43 <+1228>: add %al,(%rax) 0xffff82d080176a45 <+1230>: add %al,(%rax) 0xffff82d080176a47 <+1232>: add %al,(%rax) 0xffff82d080176a49 <+1234>: add %al,(%rax) 0xffff82d080176a4b <+1236>: add %al,(%rax) 0xffff82d080176a4d <+1238>: add %al,(%rax) 0xffff82d080176a4f <+1240>: add %al,(%rax) 0xffff82d080176a51 <+1242>: add %al,(%rax) 0xffff82d080176a53 <+1244>: add %al,(%rax) 0xffff82d080176a55 <+1246>: add %al,(%rax) 0xffff82d080176a57 <+1248>: add %al,(%rax) 0xffff82d080176a59 <+1250>: add %al,(%rax) 0xffff82d080176a5b <+1252>: add %al,(%rax) 0xffff82d080176a5d <+1254>: add %al,(%rax) 0xffff82d080176a5f <+1256>: add %al,(%rax) 0xffff82d080176a61 <+1258>: add %al,(%rax) 0xffff82d080176a63 <+1260>: add %al,(%rax) 0xffff82d080176a65 <+1262>: add %al,(%rax) 0xffff82d080176a67 <+1264>: add %al,(%rax) 0xffff82d080176a69 <+1266>: add %al,(%rax) 0xffff82d080176a6b <+1268>: add %al,(%rax) 0xffff82d080176a6d <+1270>: add %al,(%rax) 0xffff82d080176a6f <+1272>: add %al,(%rax) 0xffff82d080176a71 <+1274>: add %al,(%rax) 0xffff82d080176a73 <+1276>: add %al,(%rax) 0xffff82d080176a75 <+1278>: add %al,(%rax) 0xffff82d080176a77 <+1280>: add %al,(%rax) 0xffff82d080176a79 <+1282>: add %al,(%rax) 0xffff82d080176a7b <+1284>: add %al,(%rax) 0xffff82d080176a7d <+1286>: add %al,(%rax) 0xffff82d080176a7f <+1288>: add %al,(%rax) 0xffff82d080176a81 <+1290>: add %al,(%rax) 0xffff82d080176a83 <+1292>: add %al,(%rax) 0xffff82d080176a85 <+1294>: add %al,(%rax) 0xffff82d080176a87 <+1296>: add %al,(%rax) 0xffff82d080176a89 <+1298>: add %al,(%rax) 0xffff82d080176a8b <+1300>: add %al,(%rax) 0xffff82d080176a8d <+1302>: add %al,(%rax) 0xffff82d080176a8f <+1304>: add %al,(%rax) 0xffff82d080176a91 <+1306>: add %al,(%rax) 0xffff82d080176a93 <+1308>: add %al,(%rax) 0xffff82d080176a95 <+1310>: add %al,(%rax) 0xffff82d080176a97 <+1312>: add %al,(%rax) 0xffff82d080176a99 <+1314>: add %al,(%rax) 0xffff82d080176a9b <+1316>: add %al,(%rax) 0xffff82d080176a9d <+1318>: add %al,(%rax) 0xffff82d080176a9f <+1320>: add %al,(%rax) 0xffff82d080176aa1 <+1322>: add %al,(%rax) 0xffff82d080176aa3 <+1324>: add %al,(%rax) 0xffff82d080176aa5 <+1326>: add %al,(%rax) 0xffff82d080176aa7 <+1328>: add %al,(%rax) 0xffff82d080176aa9 <+1330>: add %al,(%rax) 0xffff82d080176aab <+1332>: add %al,(%rax) 0xffff82d080176aad <+1334>: add %al,(%rax) 0xffff82d080176aaf <+1336>: add %al,(%rax) 0xffff82d080176ab1 <+1338>: add %al,(%rax) 0xffff82d080176ab3 <+1340>: add %al,(%rax) 0xffff82d080176ab5 <+1342>: add %al,(%rax) 0xffff82d080176ab7 <+1344>: add %al,(%rax) 0xffff82d080176ab9 <+1346>: add %al,(%rax) 0xffff82d080176abb <+1348>: add %al,(%rax) 0xffff82d080176abd <+1350>: add %al,(%rax) 0xffff82d080176abf <+1352>: add %al,(%rax) 0xffff82d080176ac1 <+1354>: add %al,(%rax) 0xffff82d080176ac3 <+1356>: add %al,(%rax) 0xffff82d080176ac5 <+1358>: add %al,(%rax) 0xffff82d080176ac7 <+1360>: add %al,(%rax) 0xffff82d080176ac9 <+1362>: add %al,(%rax) 0xffff82d080176acb <+1364>: add %al,(%rax) 0xffff82d080176acd <+1366>: add %al,(%rax) 0xffff82d080176acf <+1368>: add %al,(%rax) 0xffff82d080176ad1 <+1370>: add %al,(%rax) 0xffff82d080176ad3 <+1372>: add %al,(%rax) 0xffff82d080176ad5 <+1374>: add %al,(%rax) 0xffff82d080176ad7 <+1376>: add %al,(%rax) 0xffff82d080176ad9 <+1378>: add %al,(%rax) 0xffff82d080176adb <+1380>: add %al,(%rax) 0xffff82d080176add <+1382>: add %al,(%rax) 0xffff82d080176adf <+1384>: add %al,(%rax) 0xffff82d080176ae1 <+1386>: add %al,(%rax) 0xffff82d080176ae3 <+1388>: add %al,(%rax) 0xffff82d080176ae5 <+1390>: add %al,(%rax) 0xffff82d080176ae7 <+1392>: add %al,(%rax) 0xffff82d080176ae9 <+1394>: add %al,(%rax) 0xffff82d080176aeb <+1396>: add %al,(%rax) 0xffff82d080176aed <+1398>: add %al,(%rax) 0xffff82d080176aef <+1400>: add %al,(%rax) 0xffff82d080176af1 <+1402>: add %al,(%rax) 0xffff82d080176af3 <+1404>: add %al,(%rax) 0xffff82d080176af5 <+1406>: add %al,(%rax) 0xffff82d080176af7 <+1408>: add %al,(%rax) 0xffff82d080176af9 <+1410>: add %al,(%rax) 0xffff82d080176afb <+1412>: add %al,(%rax) 0xffff82d080176afd <+1414>: add %al,(%rax) 0xffff82d080176aff <+1416>: add %al,(%rax) 0xffff82d080176b01 <+1418>: add %al,(%rax) 0xffff82d080176b03 <+1420>: add %al,(%rax) 0xffff82d080176b05 <+1422>: add %al,(%rax) 0xffff82d080176b07 <+1424>: add %al,(%rax) 0xffff82d080176b09 <+1426>: add %al,(%rax) 0xffff82d080176b0b <+1428>: add %al,(%rax) 0xffff82d080176b0d <+1430>: add %al,(%rax) 0xffff82d080176b0f <+1432>: add %al,(%rax) 0xffff82d080176b11 <+1434>: add %al,(%rax) 0xffff82d080176b13 <+1436>: add %al,(%rax) 0xffff82d080176b15 <+1438>: add %al,(%rax) 0xffff82d080176b17 <+1440>: add %al,(%rax) 0xffff82d080176b19 <+1442>: add %al,(%rax) 0xffff82d080176b1b <+1444>: add %al,(%rax) 0xffff82d080176b1d <+1446>: add %al,(%rax) 0xffff82d080176b1f <+1448>: add %al,(%rax) 0xffff82d080176b21 <+1450>: add %al,(%rax) 0xffff82d080176b23 <+1452>: add %al,(%rax) 0xffff82d080176b25 <+1454>: add %al,(%rax) 0xffff82d080176b27 <+1456>: add %al,(%rax) 0xffff82d080176b29 <+1458>: add %al,(%rax) 0xffff82d080176b2b <+1460>: add %al,(%rax) 0xffff82d080176b2d <+1462>: add %al,(%rax) 0xffff82d080176b2f <+1464>: add %al,(%rax) 0xffff82d080176b31 <+1466>: add %al,(%rax) 0xffff82d080176b33 <+1468>: add %al,(%rax) 0xffff82d080176b35 <+1470>: add %al,(%rax) 0xffff82d080176b37 <+1472>: add %al,(%rax) 0xffff82d080176b39 <+1474>: add %al,(%rax) 0xffff82d080176b3b <+1476>: add %al,(%rax) 0xffff82d080176b3d <+1478>: add %al,(%rax) 0xffff82d080176b3f <+1480>: add %al,(%rax) 0xffff82d080176b41 <+1482>: add %al,(%rax) 0xffff82d080176b43 <+1484>: add %al,(%rax) 0xffff82d080176b45 <+1486>: add %al,(%rax) 0xffff82d080176b47 <+1488>: add %al,(%rax) 0xffff82d080176b49 <+1490>: add %al,(%rax) 0xffff82d080176b4b <+1492>: add %al,(%rax) 0xffff82d080176b4d <+1494>: add %al,(%rax) 0xffff82d080176b4f <+1496>: add %al,(%rax) 0xffff82d080176b51 <+1498>: add %al,(%rax) 0xffff82d080176b53 <+1500>: add %al,(%rax) 0xffff82d080176b55 <+1502>: add %al,(%rax) 0xffff82d080176b57 <+1504>: add %al,(%rax) 0xffff82d080176b59 <+1506>: add %al,(%rax) 0xffff82d080176b5b <+1508>: add %al,(%rax) 0xffff82d080176b5d <+1510>: add %al,(%rax) 0xffff82d080176b5f <+1512>: add %al,(%rax) 0xffff82d080176b61 <+1514>: add %al,(%rax) 0xffff82d080176b63 <+1516>: add %al,(%rax) 0xffff82d080176b65 <+1518>: add %al,(%rax) 0xffff82d080176b67 <+1520>: add %al,(%rax) 0xffff82d080176b69 <+1522>: add %al,(%rax) 0xffff82d080176b6b <+1524>: add %al,(%rax) 0xffff82d080176b6d <+1526>: add %al,(%rax) 0xffff82d080176b6f <+1528>: add %al,(%rax) 0xffff82d080176b71 <+1530>: add %al,(%rax) 0xffff82d080176b73 <+1532>: add %al,(%rax) 0xffff82d080176b75 <+1534>: add %al,(%rax) 0xffff82d080176b77 <+1536>: add %al,(%rax) 0xffff82d080176b79 <+1538>: add %al,(%rax) 0xffff82d080176b7b <+1540>: add %al,(%rax) 0xffff82d080176b7d <+1542>: add %al,(%rax) 0xffff82d080176b7f <+1544>: add %al,(%rax) 0xffff82d080176b81 <+1546>: add %al,(%rax) 0xffff82d080176b83 <+1548>: add %al,(%rax) 0xffff82d080176b85 <+1550>: add %al,(%rax) 0xffff82d080176b87 <+1552>: add %al,(%rax) 0xffff82d080176b89 <+1554>: add %al,(%rax) 0xffff82d080176b8b <+1556>: add %al,(%rax) 0xffff82d080176b8d <+1558>: add %al,(%rax) 0xffff82d080176b8f <+1560>: add %al,(%rax) 0xffff82d080176b91 <+1562>: add %al,(%rax) 0xffff82d080176b93 <+1564>: add %al,(%rax) 0xffff82d080176b95 <+1566>: add %al,(%rax) 0xffff82d080176b97 <+1568>: add %al,(%rax) 0xffff82d080176b99 <+1570>: add %al,(%rax) 0xffff82d080176b9b <+1572>: add %al,(%rax) 0xffff82d080176b9d <+1574>: add %al,(%rax) 0xffff82d080176b9f <+1576>: add %al,(%rax) 0xffff82d080176ba1 <+1578>: add %al,(%rax) 0xffff82d080176ba3 <+1580>: add %al,(%rax) 0xffff82d080176ba5 <+1582>: add %al,(%rax) 0xffff82d080176ba7 <+1584>: add %al,(%rax) 0xffff82d080176ba9 <+1586>: add %al,(%rax) 0xffff82d080176bab <+1588>: add %al,(%rax) 0xffff82d080176bad <+1590>: add %al,(%rax) 0xffff82d080176baf <+1592>: add %al,(%rax) 0xffff82d080176bb1 <+1594>: add %al,(%rax) 0xffff82d080176bb3 <+1596>: add %al,(%rax) 0xffff82d080176bb5 <+1598>: add %al,(%rax) 0xffff82d080176bb7 <+1600>: add %al,(%rax) 0xffff82d080176bb9 <+1602>: add %al,(%rax) 0xffff82d080176bbb <+1604>: add %al,(%rax) 0xffff82d080176bbd <+1606>: add %al,(%rax) 0xffff82d080176bbf <+1608>: add %al,(%rax) 0xffff82d080176bc1 <+1610>: add %al,(%rax) End of assembler dump. [-- Attachment #5: dmesg --] [-- Type: text/plain, Size: 28032 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=n Sat Nov 14 00:50:05 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.435787] Detected 2394.592 MHz processor. (XEN) [ 1.443167] Initing memory sharing. (XEN) [ 1.447492] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.454435] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.464415] Intel machine check reporting enabled (XEN) [ 1.470025] alt table ffff82d0802cfa90 -> ffff82d0802d0bd0 (XEN) [ 1.476364] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.484920] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.490988] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.497615] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.503856] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.510090] Intel VT-d Snoop Control not enabled. (XEN) [ 1.515754] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.521907] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.527629] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.533435] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.547704] I/O virtualisation enabled (XEN) [ 1.552284] - Dom0 mode: Relaxed (XEN) [ 1.556440] Interrupt remapping enabled (XEN) [ 1.561331] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.567697] ENABLING IO-APIC IRQs (XEN) [ 1.571844] -> Using old ACK method (XEN) [ 1.576568] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.785867] TSC deadline timer enabled (XEN) [ 2.016050] Platform timer is 14.318MHz HPET (XEN) [ 2.020833] Allocated console ring of 64 KiB. (XEN) [ 2.021967] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.023016] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.023529] mwait-idle: v0.4 model 0x2a (XEN) [ 2.024037] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.024598] VMX: Supported advanced features: (XEN) [ 2.025109] - APIC MMIO access virtualisation (XEN) [ 2.025620] - APIC TPR shadow (XEN) [ 2.026373] - Extended Page Tables (EPT) (XEN) [ 2.026882] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.027396] - Virtual NMI (XEN) [ 2.027931] - MSR direct-access bitmap (XEN) [ 2.028440] - Unrestricted Guest (XEN) [ 2.028945] HVM: ASIDs enabled. (XEN) [ 2.029486] HVM: VMX enabled (XEN) [ 2.029987] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.030504] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.031658] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.032693] Brought up 8 CPUs (XEN) [ 2.033214] microcode: CPU7 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.039867] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.040383] microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.061561] ACPI sleep modes: S3 (XEN) [ 2.062066] mcheck_poll: Machine check polling timer started. (XEN) [ 2.062597] Dom0 has maximum 792 PIRQs (XEN) [ 2.063184] *** LOADING DOMAIN 0 *** (XEN) [ 2.244646] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 2.245196] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 2.246430] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 2.246938] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 2.247995] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 2.248520] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 2.249028] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 2.249549] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 2.250068] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 2.250809] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 2.251328] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 2.251847] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 2.252366] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 2.252920] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 2.254260] Dom0 has maximum 8 VCPUs (XEN) [ 5.419481] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 5.427778] Std. Loglevel: All (XEN) [ 5.428320] Guest Loglevel: All (XEN) [ 5.428824] Xen is relinquishing VGA console. (XEN) [ 5.429901] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) [ 5.429939] Freed 316kB init memory. (XEN) [ 5.686219] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.686224] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) [ 5.686227] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) [ 5.686231] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.686234] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) [ 5.686238] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.686241] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.777389] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.777396] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080cab3000 to 0xffffffff81646d10. (XEN) [ 5.777402] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080cab3080 to 0xffffffff81648e70. (XEN) [ 5.777407] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.777412] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000175 from 0xffff83080cab7fc0 to 0x0000000000000000. (XEN) [ 5.777417] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.777421] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.777710] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.777715] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000082 from 0xffff83080caa3000 to 0xffffffff81646d10. (XEN) [ 5.777719] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000083 from 0xffff83080caa3080 to 0xffffffff81648e70. (XEN) [ 5.777723] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.777726] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000175 from 0xffff83080caa7fc0 to 0x0000000000000000. (XEN) [ 5.777729] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.777733] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.777959] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.777963] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca93000 to 0xffffffff81646d10. (XEN) [ 5.777966] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca93080 to 0xffffffff81648e70. (XEN) [ 5.777969] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.777973] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca97fc0 to 0x0000000000000000. (XEN) [ 5.777976] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.777979] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.778177] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.778182] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca83000 to 0xffffffff81646d10. (XEN) [ 5.778186] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca83080 to 0xffffffff81648e70. (XEN) [ 5.778189] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.778193] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca87fc0 to 0x0000000000000000. (XEN) [ 5.778196] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.778199] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.778401] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.778405] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063f3000 to 0xffffffff81646d10. (XEN) [ 5.778409] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063f3080 to 0xffffffff81648e70. (XEN) [ 5.778412] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.778415] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000175 from 0xffff8308063f7fc0 to 0x0000000000000000. (XEN) [ 5.778418] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.778421] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.778618] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.778623] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063eb000 to 0xffffffff81646d10. (XEN) [ 5.778626] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063eb080 to 0xffffffff81648e70. (XEN) [ 5.778630] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.778634] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000175 from 0xffff8308063effc0 to 0x0000000000000000. (XEN) [ 5.778637] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.778640] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.778873] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.778877] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063db000 to 0xffffffff81646d10. (XEN) [ 5.778881] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063db080 to 0xffffffff81648e70. (XEN) [ 5.778884] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.778887] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000175 from 0xffff8308063dffc0 to 0x0000000000000000. (XEN) [ 5.778890] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.778894] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.926550] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 6.926553] PCI add device 0000:00:00.0 (XEN) [ 6.926749] PCI add device 0000:00:01.0 (XEN) [ 6.926931] PCI add device 0000:00:01.1 (XEN) [ 6.927169] PCI add device 0000:00:02.0 (XEN) [ 6.927357] PCI add device 0000:00:06.0 (XEN) [ 6.927641] PCI add device 0000:00:16.0 (XEN) [ 6.927937] PCI add device 0000:00:19.0 (XEN) [ 6.928233] PCI add device 0000:00:1a.0 (XEN) [ 6.928517] PCI add device 0000:00:1b.0 (XEN) [ 6.928775] PCI add device 0000:00:1c.0 (XEN) [ 6.929035] PCI add device 0000:00:1c.4 (XEN) [ 6.929290] PCI add device 0000:00:1c.6 (XEN) [ 6.929586] PCI add device 0000:00:1d.0 (XEN) [ 6.929780] PCI add device 0000:00:1e.0 (XEN) [ 6.930034] PCI add device 0000:00:1f.0 (XEN) [ 6.930310] PCI add device 0000:00:1f.2 (XEN) [ 6.930492] PCI add device 0000:00:1f.3 (XEN) [ 6.930763] PCI add device 0000:01:00.0 (XEN) [ 6.948211] PCI add device 0000:02:00.0 (XEN) [ 6.968249] PCI add device 0000:03:00.0 (XEN) [ 6.968685] PCI add device 0000:04:00.0 (XEN) [ 6.988444] PCI add device 0000:05:00.0 (XEN) [ 6.988869] PCI add device 0000:06:00.0 (XEN) [ 6.989589] PCI add device 0000:07:00.0 (XEN) [ 7.008479] PCI add device 0000:08:00.0 (XEN) [ 7.008775] PCI add device 0000:09:00.0 (XEN) [ 7.009266] PCI add device 0000:0a:08.0 (XEN) [ 7.009552] PCI add device 0000:0a:09.0 (XEN) [ 7.009835] PCI add device 0000:0a:0a.0 (XEN) [ 7.010115] PCI add device 0000:0a:0b.0 (XEN) [ 7.071573] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071594] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071639] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071658] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071675] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071684] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071729] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.071748] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (d1) [ 34.982476] HVM Loader (d1) [ 34.982818] Detected Xen v4.5.2 (d1) [ 34.983206] Xenbus rings @0xfeffc000, event channel 1 (d1) [ 34.983622] System requested SeaBIOS (d1) [ 34.983826] CPU speed is 2395 MHz (d1) [ 34.984489] Relocating guest memory for lowmem MMIO space disabled (XEN) [ 34.985061] irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (d1) [ 34.985401] PCI-ISA link 0 routed to IRQ5 (XEN) [ 34.985649] irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (d1) [ 34.985993] PCI-ISA link 1 routed to IRQ10 (XEN) [ 34.986214] irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (d1) [ 34.986566] PCI-ISA link 2 routed to IRQ11 (XEN) [ 34.986766] irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (d1) [ 34.987136] PCI-ISA link 3 routed to IRQ5 (d1) [ 35.004032] pci dev 01:3 INTA->IRQ10 (d1) [ 35.007014] pci dev 02:0 INTA->IRQ11 (d1) [ 35.014288] pci dev 04:0 INTA->IRQ5 (d1) [ 35.018608] pci dev 05:0 INTA->IRQ10 (d1) [ 35.022666] pci dev 06:0 INTA->IRQ11 (d1) [ 35.047933] No RAM in high memory; setting high_mem resource base to 100000000 (d1) [ 35.048483] pci dev 03:0 bar 10 size 002000000: 0f0000008 (d1) [ 35.050606] pci dev 02:0 bar 14 size 001000000: 0f2000008 (d1) [ 35.052697] pci dev 04:0 bar 10 size 000020000: 0f3000004 (XEN) [ 35.052893] memory_map:add: dom1 gfn=f3000 mfn=f7c00 nr=20 (d1) [ 35.056201] pci dev 03:0 bar 30 size 000010000: 0f3020000 (d1) [ 35.056814] pci dev 04:0 bar 30 size 000010000: 0f3030000 (d1) [ 35.057420] pci dev 05:0 bar 30 size 000010000: 0f3040000 (d1) [ 35.058021] pci dev 06:0 bar 10 size 000010000: 0f3050000 (XEN) [ 35.058203] memory_map:add: dom1 gfn=f3050 mfn=f7800 nr=10 (d1) [ 35.062960] pci dev 03:0 bar 14 size 000001000: 0f3060000 (XEN) [ 35.063253] memory_map:add: dom1 gfn=f3061 mfn=f7842 nr=1 (d1) [ 35.067114] pci dev 05:0 bar 14 size 000001000: 0f3061000 (d1) [ 35.067645] pci dev 02:0 bar 10 size 000000100: 00000c001 (d1) [ 35.069953] pci dev 05:0 bar 10 size 000000100: 00000c101 (XEN) [ 35.070376] ioport_map:add: dom1 gport=c100 mport=c200 nr=100 (d1) [ 35.073641] pci dev 01:1 bar 20 size 000000010: 00000c201 (d1) [ 35.075752] Multiprocessor initialisation: (d1) [ 35.100556] - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 35.115647] - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 35.115712] Testing HVM environment: (d1) [ 35.119040] - REP INSB across page boundaries ... passed (d1) [ 35.120996] - GS base MSRs and SWAPGS ... passed (d1) [ 35.121017] Passed 2 of 2 tests (d1) [ 35.121042] Writing SMBIOS tables ... (d1) [ 35.121771] Loading SeaBIOS ... (d1) [ 35.121810] Creating MP tables ... (d1) [ 35.121899] Loading ACPI ... (d1) [ 35.123225] vm86 TSS at fc00a380 (d1) [ 35.123481] BIOS map: (d1) [ 35.123509] 10000-100d3: Scratch space (d1) [ 35.123532] e0000-fffff: Main BIOS (d1) [ 35.123545] E820 table: (d1) [ 35.123592] [00]: 00000000:00000000 - 00000000:000a0000: RAM (d1) [ 35.123635] HOLE: 00000000:000a0000 - 00000000:000e0000 (d1) [ 35.123687] [01]: 00000000:000e0000 - 00000000:00100000: RESERVED (d1) [ 35.123735] [02]: 00000000:00100000 - 00000000:27800000: RAM (d1) [ 35.123777] HOLE: 00000000:27800000 - 00000000:fc000000 (d1) [ 35.123830] [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d1) [ 35.124046] Invoking SeaBIOS ... (XEN) [ 36.000827] Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) [ 36.000830] ************* VMCS Area ************** (XEN) [ 36.000832] *** Guest State *** (XEN) [ 36.000833] CR0: actual=0x0000000000000039, shadow=0x0000000000000011, gh_mask=ffffffffffffffff (XEN) [ 36.000836] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) [ 36.000838] CR3: actual=0x0000000000800000, target_count=0 (XEN) [ 36.000839] target0=0000000000000000, target1=0000000000000000 (XEN) [ 36.000840] target2=0000000000000000, target3=0000000000000000 (XEN) [ 36.000842] RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = 0x0000000100000000 (0x0000000100000000) (XEN) [ 36.000844] RFLAGS=0x0000000000000006 (0x0000000000000006) DR7 = 0x0000000000000400 (XEN) [ 36.000846] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) [ 36.000848] CS: sel=0x0008, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000850] DS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000852] SS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000854] ES: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000856] FS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000858] GS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.000860] GDTR: limit=0x00000037, base=0x00000000000f6d80 (XEN) [ 36.000861] LDTR: sel=0x0000, attr=0x00082, limit=0x00000000, base=0x0000000000000000 (XEN) [ 36.000863] IDTR: limit=0x00000000, base=0x00000000000f6dbe (XEN) [ 36.000865] TR: sel=0x0000, attr=0x0008b, limit=0x000000ff, base=0x0000000000000000 (XEN) [ 36.000866] Guest PAT = 0x0007040600070406 (XEN) [ 36.000868] TSC Offset = ffffffe7284b90c0 (XEN) [ 36.000869] DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) [ 36.000871] Interruptibility=0000 ActivityState=0000 (XEN) [ 36.000872] *** Host State *** (XEN) [ 36.000874] RSP = 0xffff8308063eff90 RIP = 0xffff82d0801f4820 (XEN) [ 36.000875] CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) [ 36.000877] FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff8308063f8c80 (XEN) [ 36.000879] GDTBase=ffff8308063ec000 IDTBase=ffff8308063e6000 (XEN) [ 36.000881] CR0=000000008005003b CR3=000000070bf71000 CR4=00000000000426f0 (XEN) [ 36.000883] Sysenter RSP=ffff8308063effc0 CS:RIP=e008:ffff82d080235550 (XEN) [ 36.000885] Host PAT = 0x0000050100070406 (XEN) [ 36.000886] *** Control State *** (XEN) [ 36.000887] PinBased=0000003f CPUBased=b6a065fe SecondaryExec=000000eb (XEN) [ 36.000889] EntryControls=000051ff ExitControls=000fefff (XEN) [ 36.000890] ExceptionBitmap=000600c2 (XEN) [ 36.000891] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.000893] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.000894] reason=80000021 qualification=00000000 (XEN) [ 36.000896] IDTVectoring: info=00000000 errcode=00000000 (XEN) [ 36.000897] TPR Threshold = 0x00 (XEN) [ 36.000898] EPT pointer = 0x000000070bf3f01e (XEN) [ 36.000899] Virtual processor ID = 0x000a (XEN) [ 36.000901] ************************************** (XEN) [ 36.000902] domain_crash called from vmx.c:2505 (XEN) [ 36.000904] Domain 1 (vcpu#0) crashed on cpu#6: (XEN) [ 36.000906] ----[ Xen-4.5.2 x86_64 debug=n Not tainted ]---- (XEN) [ 36.000908] CPU: 6 (XEN) [ 36.000909] RIP: 0008:[<0000000100000000>] (XEN) [ 36.000910] RFLAGS: 0000000000000006 CONTEXT: hvm guest (d1v0) (XEN) [ 36.000913] rax: 0000000000000000 rbx: 0000000000000000 rcx: 00000000ffff1720 (XEN) [ 36.000915] rdx: 0000000000000059 rsi: 0000000000000059 rdi: 0000000000000000 (XEN) [ 36.000917] rbp: 0000000000000000 rsp: 0000000000006fdc r8: 0000000000000000 (XEN) [ 36.000918] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 36.000920] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 36.000921] r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) [ 36.000923] cr3: 0000000000800000 cr2: 0000000000000000 (XEN) [ 36.000925] ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 [-- Attachment #6: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-14 0:16 ` Atom2 @ 2015-11-14 20:32 ` Andrew Cooper 2015-11-15 0:14 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-14 20:32 UTC (permalink / raw) To: Atom2; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 10075 bytes --] On 14/11/2015 00:16, Atom2 wrote: > Am 13.11.15 um 11:09 schrieb Andrew Cooper: >> On 13/11/15 07:25, Jan Beulich wrote: >>>>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >>>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>>> On 12/11/15 14:29, Atom2 wrote: >>>>>> Hi Andrew, >>>>>> thanks for your reply. Answers are inline further down. >>>>>> >>>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>>>> of the >>>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>>> >>>>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>>>> domU which is started as part of the machine booting up: >>>>>>>>> [...] >>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>>> state (0). >>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>> (XEN) *** Guest State *** >>>>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>>> odd? That will be the source of the failure. >>>>>>> >>>>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>>>> should not be possible to set any of them. >>>>>>> >>>>>>> I suspect that the guest has exited for emulation, and there has been a >>>>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>>>> that there is a hardware errata which allows the guest to accidentally >>>>>>> get it self into this condition. >>>>>>> >>>>>>> Are you able to rerun with a debug build of the hypervisor? >>>>>> [snip] >>>>>> Another question is whether prior to enabling the debug USE flag it >>>>>> might make sense to re-compile with gcc-4.8.5 (please see my previous >>>>>> list reply) to rule out any compiler related issues. Jan, Andrew - >>>>>> what are your thoughts? >>>>> First of all, check whether the compiler makes a difference on 4.5.2 >>>> Hi Andrew, >>>> I changed the compiler and there was no change to the better: >>>> Unfortunately the HVM domU is still crashing with a similar error >>>> message as soon as it is being started. >>>>> If both compiles result in a guest crashing in that manner, test a debug >>>>> Xen to see if any assertions/errors are encountered just before the >>>>> guest crashes. >>>>> >>>> As the compiler did not make any difference, I enabled the debug USE >>>> flag, re-compiled (using gcc-4.9.3), and rebooted using a serial console >>>> to capture output. Unfortunately I did not get very far and things >>>> become even stranger: This time the system did not even finnish the boot >>>> process, but rather hard-stopped pretty early with a message reading >>>> "Panic on CPU 3: DOUBLE FAULT -- system shutdown". The captured logfile >>>> is attached as "serial log.txt". >>>> >>>> As this happened immediately after the CPU microcode update, I thought >>>> there might be a connection and disabled the microcode update. After the >>>> next reboot it seemed as if the boot process got a bit further as >>>> evidenced by a few more lines in the log file (those between lines 136 >>>> and 197 in the second log file named "serial log no ucode.txt"), but in >>>> the end it finnished off with an identical error message (only the CPU # >>>> was different this time, but that number seems to change between boots >>>> anyways). >>>> >>>> I hope that makes some sense to you. >>> Not really, other than now even more suspecting bad hardware or >>> something fundamentally wrong with your build. Did you retry with >>> a freshly built 4.5.1? Could you alternatively try with a known good >>> build of 4.5.2 (e.g. from osstest)? > Andrew, > many thanks again for your help. >> Agreed. Double faults indicate that the exception handing entry points >> are not set up in an appropriate state. Something is definitely wrong >> with either the compiled binary or the hardware. > The hardware (it's a SandyBridge XEON processor with ECC RAM and > Enterprise SATA disks) has worked for almost two years together with > XEN and other than this issue there's also currently nothing strange > (i.e. if I boot with a standard linux kernel, the system boots and > works without any issues and is very stable and there are also no > strange messages in /var/log/messages). >> Several questions and lines of investigation: >> >> Is this straight Xen 4.5.1 and 2, or do Gentoo have their own patches on >> top? > By the looks of it there are only security patches, but no gentoo > specific patches. >> On repeated attempts, are the details of the double fault identical >> (other than the cpu), or does it move around (i.e. always do_IRQ+0x15) > It always seems to be do_IRQ+0x15 (I have made a number of boots), and > more specifically it was always do_IRQ+0x15/0x64c. Timings varied, the > CPU differed between boots and also the rax, rbx, rcx, rdx, rsi, rdi, > rbp, rsp, and r8 values were diffent as were those for r15 and cr2 and > the values next to valid stack range. I don't know whether that's of > relevance, but I thought I'd mention it after a quick analysis of two > serial logs. >> Can you boot with console_timestamps=boot on the command line in the >> future. This will put Linux-sytle timestamps on log messages. > Done - see two the attached serial log files mentioned above. >> Can you also compile in the attached patch? I haven't quite got it >> suitable for inclusion upstream yet, but it will also dump the >> instruction stream under the fault. > I have added the patch, but it seems not to trigger - at least the > text that is in the patch does not show in the serial console output; > it is however in the (uncompressed) xen.gz file as a quick grep for > texts "Xen code around " and " [fault on access]" confirmed (grep > said: binary file matches). >> Finally, can you disassemble the xen-syms which results from the debug >> build and paste the start of do_IRQ. (i.e. `gdb xen-syms` and "disass >> do_IRQ") > Please see the third file named "do_IRQ". > > Furthermore I have managed to get the system to again boot up (a HVM > domU, however, still crashes): If I turn off the debug USE flag and > just add symbols to the XEN binary. It seems that the debug USE flag > is probably not what I was expecting. On > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces it > describes the purpose of the debug USE flag as follows (emphasis by me): > > ==== start excerpt from web page ==== > Some ebuilds provide a *debug* USE flag. While some mistakenly use it > to provide debug information and play with compiler flags when it is > enabled, that is not its purpose. > > _If you're trying to debug a reproduceable crash, you want to leave > this USE flag alone, as it'll be building a different source than what > you had before._ It is more efficient to get first a backtrace without > changing the code, by simply emitting symbol information, and just > afterward enable debug features to track the issue further down. > > Debug features that are enabled by the USE flag include assertions, > debug logs on screen, debug files, leak detection and extra-safe > operations (such as scrubbing memory before use). Some of them might > be taxing, especially for complex software or software where > performance is an important issue. > > For these reasons, please exercise caution when enabling the *debug* > USE flag, and only consider it a last-chance card. > ==== end excerpt from web page ==== > > Now _without_ the debug USE flag, but with debug information in the > binary (I used splitdebug), all is back to where the problem started > off (i.e. the system boots without issues until such time it starts a > HVM domU which then crashes; PV domUs are working). I have attached > the latest "xl dmesg" output with the timing information included. > > I hope any of this makes sense to you. > > Again many thanks and best regards > Right - it would appear that the USE flag is definitely not what you wanted, and causes bad compilation for Xen. The do_IRQ disassembly you sent is a the result of disassembling a whole block of zeroes. Sorry for leading you on a goose chase - the double faults will be the product of bad compilation, rather than anything to do with your specific problem. However, the final log you sent (dmesg) is using a debug Xen, which is what I was attempting to get you to do originally. We still observe that the VM ends up in 32bit non-paged mode but with an RIP with bit 32 set, which is an invalid state to be in. However, there was nothing particularly interesting in the extra log information. Please can you rerun with "hvm_debug=0xc3f", which will cause far more logging to occur to the console while the HVM guest is running. That might show some hints. Also, the fact that this occurs just after starting SeaBIOS is interesting. As you have switched versions of Xen, you have also switched hvmloader, which contains the SeaBIOS binary embedded in it. Would you be able to compile both 4.5.1 and 4.5.2 and switch the hvmloader binaries in use. It would be very interesting to see whether the failure is caused by the hvmloader binary or the hypervisor. (With `xl`, you can use firmware_override="/full/path/to/firmware" to override the default hvmloader). Thanks, ~Andrew [-- Attachment #1.2: Type: text/html, Size: 13334 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-14 20:32 ` Andrew Cooper @ 2015-11-15 0:14 ` Atom2 2015-11-15 15:12 ` Andrew Cooper 2015-11-15 20:12 ` Doug Goldstein 0 siblings, 2 replies; 43+ messages in thread From: Atom2 @ 2015-11-15 0:14 UTC (permalink / raw) To: Andrew Cooper; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 6753 bytes --] Am 14.11.15 um 21:32 schrieb Andrew Cooper: > On 14/11/2015 00:16, Atom2 wrote: >> Am 13.11.15 um 11:09 schrieb Andrew Cooper: >>> On 13/11/15 07:25, Jan Beulich wrote: >>>>>>> On 13.11.15 at 00:00,<ariel.atom2@web2web.at> wrote: >>>>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>>>> On 12/11/15 14:29, Atom2 wrote: >>>>>>> Hi Andrew, >>>>>>> thanks for your reply. Answers are inline further down. >>>>>>> >>>>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>>>> On 12.11.15 at 02:08,<ariel.atom2@web2web.at> wrote: >>>>>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>>>>> of the >>>>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>>>> >>>>>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>>>>> domU which is started as part of the machine booting up: >>>>>>>>>> [...] >>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>>>> state (0). >>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>>>> odd? That will be the source of the failure. >>>>>>>> >>>>>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>>>>> should not be possible to set any of them. >>>>>>>> >>>>>>>> I suspect that the guest has exited for emulation, and there has been a >>>>>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>>>>> that there is a hardware errata which allows the guest to accidentally >>>>>>>> get it self into this condition. >>>>>>>> >>>>>>>> Are you able to rerun with a debug build of the hypervisor? [big snip] >>>>>>> Now _without_ the debug USE flag, but with debug information in >>>>>>> the binary (I used splitdebug), all is back to where the problem >>>>>>> started off (i.e. the system boots without issues until such >>>>>>> time it starts a HVM domU which then crashes; PV domUs are >>>>>>> working). I have attached the latest "xl dmesg" output with the >>>>>>> timing information included. >>>>>>> >> >> I hope any of this makes sense to you. >> >> Again many thanks and best regards >> > > Right - it would appear that the USE flag is definitely not what you > wanted, and causes bad compilation for Xen. The do_IRQ disassembly > you sent is a the result of disassembling a whole block of zeroes. > Sorry for leading you on a goose chase - the double faults will be the > product of bad compilation, rather than anything to do with your > specific problem. Hi Andrew, there's absolutely no need to appologize as it is me who asked for help and you who generously stepped in and provided it. I really do appreciate your help and it is for me, as the one seeking help, to provide all the information you deem necessary and you ask for. > However, the final log you sent (dmesg) is using a debug Xen, which is > what I was attempting to get you to do originally. Next time I know better how to arrive at a debug XEN. It's all about learning. > We still observe that the VM ends up in 32bit non-paged mode but with > an RIP with bit 32 set, which is an invalid state to be in. However, > there was nothing particularly interesting in the extra log information. > > Please can you rerun with "hvm_debug=0xc3f", which will cause far more > logging to occur to the console while the HVM guest is running. That > might show some hints. I haven't done that yet - but please see my next paragraph. If you are still interested in this, for whatever reason, I am clearly more than happy to rerun with your suggested option and provide that information as well. > Also, the fact that this occurs just after starting SeaBIOS is > interesting. As you have switched versions of Xen, you have also > switched hvmloader, which contains the SeaBIOS binary embedded in it. > Would you be able to compile both 4.5.1 and 4.5.2 and switch the > hvmloader binaries in use. It would be very interesting to see > whether the failure is caused by the hvmloader binary or the > hypervisor. (With `xl`, you can use > firmware_override="/full/path/to/firmware" to override the default > hvmloader). Your analysis was absolutely spot on. After re-thinking this for a moment, I thought going down that route first would make a lot of sense as PV guests still do work and one of the differences to HVM domUs is that the former do _not_ require SeaBIOS. Looking at my log files of installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in the relevant timeframe which obviously had not made it to the hvmloader of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed to strongly indicate that there indeed might be an issue with SeaBIOS as this probably was the only variable that had changed from the original install of xen-4.5.1. My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile xen-4.5.1. Voila, the system was again up and running. While still having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you probably guessed it ... the problem was gone: The system boots up with no issues and everything is fine again. So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 preventing HVM doamins from successfully starting up. I don't know what this is triggered from, if this is specific to my hardware or whether something else in my environment is to blame. In any case, I am again more than happy to provide data / run a few tests should you wish to get to the grounds of this. I do owe you a beer (or any other drink) should you ever be at my location (i.e. Vienna, Austria). Many thanks again for your analysis and your first class support. Xen and their people absolutely rock! Atom2 [-- Attachment #1.2: Type: text/html, Size: 9770 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-15 0:14 ` Atom2 @ 2015-11-15 15:12 ` Andrew Cooper 2015-11-16 0:39 ` Atom2 2015-11-15 20:12 ` Doug Goldstein 1 sibling, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-15 15:12 UTC (permalink / raw) To: Atom2; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 4507 bytes --] On 15/11/15 00:14, Atom2 wrote: > >> Right - it would appear that the USE flag is definitely not what you >> wanted, and causes bad compilation for Xen. The do_IRQ disassembly >> you sent is a the result of disassembling a whole block of zeroes. >> Sorry for leading you on a goose chase - the double faults will be >> the product of bad compilation, rather than anything to do with your >> specific problem. > Hi Andrew, > there's absolutely no need to appologize as it is me who asked for > help and you who generously stepped in and provided it. I really do > appreciate your help and it is for me, as the one seeking help, to > provide all the information you deem necessary and you ask for. >> However, the final log you sent (dmesg) is using a debug Xen, which >> is what I was attempting to get you to do originally. > Next time I know better how to arrive at a debug XEN. It's all about > learning. >> We still observe that the VM ends up in 32bit non-paged mode but with >> an RIP with bit 32 set, which is an invalid state to be in. However, >> there was nothing particularly interesting in the extra log information. >> >> Please can you rerun with "hvm_debug=0xc3f", which will cause far >> more logging to occur to the console while the HVM guest is running. >> That might show some hints. > I haven't done that yet - but please see my next paragraph. If you are > still interested in this, for whatever reason, I am clearly more than > happy to rerun with your suggested option and provide that information > as well. >> Also, the fact that this occurs just after starting SeaBIOS is >> interesting. As you have switched versions of Xen, you have also >> switched hvmloader, which contains the SeaBIOS binary embedded in >> it. Would you be able to compile both 4.5.1 and 4.5.2 and switch the >> hvmloader binaries in use. It would be very interesting to see >> whether the failure is caused by the hvmloader binary or the >> hypervisor. (With `xl`, you can use >> firmware_override="/full/path/to/firmware" to override the default >> hvmloader). > Your analysis was absolutely spot on. After re-thinking this for a > moment, I thought going down that route first would make a lot of > sense as PV guests still do work and one of the differences to HVM > domUs is that the former do _not_ require SeaBIOS. Looking at my log > files of installed packages confirmed an upgrade from SeaBIOS 1.7.5 to > 1.8.2 in the relevant timeframe which obviously had not made it to the > hvmloader of xen-4.5.1 as I did not re-compile xen after the upgrade > of SeaBIOS. > > So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS > 1.8.2) and the same error as with xen-4.5.2 popped up - and that > seemed to strongly indicate that there indeed might be an issue with > SeaBIOS as this probably was the only variable that had changed from > the original install of xen-4.5.1. > > My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile > xen-4.5.1. Voila, the system was again up and running. While still > having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... > you probably guessed it ... the problem was gone: The system boots up > with no issues and everything is fine again. > > So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 > preventing HVM doamins from successfully starting up. I don't know > what this is triggered from, if this is specific to my hardware or > whether something else in my environment is to blame. > > In any case, I am again more than happy to provide data / run a few > tests should you wish to get to the grounds of this. > > I do owe you a beer (or any other drink) should you ever be at my > location (i.e. Vienna, Austria). > > Many thanks again for your analysis and your first class support. Xen > and their people absolutely rock! Great - so confirms the issue as a SeaBIOS interaction issue, rather than a hypervisor regression. As I said before, I am still certain that a guest should not be able to get itself into the crashing state (short of a hardware errata), so I still suspect that there is a latent hypervisor emulation bug which has been tickled by the SeaBIOS update. Would you please mind running the bad HVMLoader on Xen 4.5.2 with hvm_debug=0xc3f ? I am still hoping that that will shed some light on SeaBIOS actions just leading up to the crash. Are you able to experiment with newer versions of Xen? It would be interesting to see whether the issue is still present in Xen 4.6 ~Andrew [-- Attachment #1.2: Type: text/html, Size: 5893 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-15 15:12 ` Andrew Cooper @ 2015-11-16 0:39 ` Atom2 2015-11-16 10:02 ` Andrew Cooper 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-16 0:39 UTC (permalink / raw) To: Andrew Cooper; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1671 bytes --] Am 15.11.15 um 16:12 schrieb Andrew Cooper: [big snip] > Great - so confirms the issue as a SeaBIOS interaction issue, rather > than a hypervisor regression. > > As I said before, I am still certain that a guest should not be able > to get itself into the crashing state (short of a hardware errata), so > I still suspect that there is a latent hypervisor emulation bug which > has been tickled by the SeaBIOS update. > > Would you please mind running the bad HVMLoader on Xen 4.5.2 with > hvm_debug=0xc3f ? I am still hoping that that will shed some light on > SeaBIOS actions just leading up to the crash. Hi Andrew, Please see the attached two files. One is the dmesg from booting the system. This looks pretty normal in my view. The other is the output of "xl dmesg" which is most likely what you were after. It's probably worth noting that the "traps.c" output between lines 259 and 314 and again between lines 346 and 353 seem to be xen-4.5.2 specific and don't show up under xen-4.5.1, but that may not be of any relevance for the SeaBIOS issue we are experiencing. Though I'd still be interested to know whether that's anything for me to worry about ... > > Are you able to experiment with newer versions of Xen? It would be > interesting to see whether the issue is still present in Xen 4.6 Currently xen-4.6 is not stable in gentoo and I try to stick to stable packages as much as possible. But in case the above does not help you any further, I am happy to give this a try as well. Would this just be a straightforward test to see whether it works at all or would you require debug symbols as well? Many thanks again and best regards Atom2 [-- Attachment #1.2: Type: text/html, Size: 2323 bytes --] [-- Attachment #2: dmesg --] [-- Type: text/plain, Size: 61348 bytes --] [ 0.000000] PAT configuration [0-7]: WB WT UC- UC WC WP UC UC [ 0.000000] Linux version 4.1.7-hardened-r1 (root@vm-host) (gcc version 4.9.3 (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) ) #1 SMP Wed Nov 11 11:47:43 CET 2015 [ 0.000000] Command line: placeholder root=UUID=aeaa7943-af67-42eb-b6f9-e73ebf7296de ro rootflags=subvol=rootfs console=hvc0 earlyprintk=xen i915.modeset=1 xen-pciback.hide=(00:1b.0)(00:1d.0)(01:00.0)(02:00.0)(03:00.0)(04:00.0)(05:00.0)(06:00.0)(08:00.0)(0a:08.0)(0a:09.0)(0a:0a.0)(0a:0b.0) softlevel=xen.d [ 0.000000] Released 0 page(s) [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable [ 0.000000] Xen: [mem 0x000000000009d800-0x00000000000fffff] reserved [ 0.000000] Xen: [mem 0x0000000000100000-0x000000001fffffff] usable [ 0.000000] Xen: [mem 0x0000000020000000-0x00000000201fffff] reserved [ 0.000000] Xen: [mem 0x0000000020200000-0x000000003fffffff] usable [ 0.000000] Xen: [mem 0x0000000040000000-0x00000000401fffff] reserved [ 0.000000] Xen: [mem 0x0000000040200000-0x00000000db9effff] usable [ 0.000000] Xen: [mem 0x00000000db9f0000-0x00000000dc0d9fff] reserved [ 0.000000] Xen: [mem 0x00000000dc0da000-0x00000000dc1f8fff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dc1f9000-0x00000000dc650fff] reserved [ 0.000000] Xen: [mem 0x00000000dc651000-0x00000000dc651fff] usable [ 0.000000] Xen: [mem 0x00000000dc652000-0x00000000dc694fff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dc695000-0x00000000dcdb9fff] usable [ 0.000000] Xen: [mem 0x00000000dcdba000-0x00000000dcff1fff] reserved [ 0.000000] Xen: [mem 0x00000000dcff2000-0x00000000dcffffff] usable [ 0.000000] Xen: [mem 0x00000000dd800000-0x00000000df9fffff] reserved [ 0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed03fff] reserved [ 0.000000] Xen: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved [ 0.000000] Xen: [mem 0x00000000fed90000-0x00000000fed91fff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved [ 0.000000] Xen: [mem 0x00000000ff000000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x000000012433efff] usable [ 0.000000] Xen: [mem 0x000000012433f000-0x000000081e5fffff] unusable [ 0.000000] bootconsole [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: iEi B199/B199, BIOS V38IAR10 07/16/2014 [ 0.000000] Hypervisor detected: Xen [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000000] e820: last_pfn = 0x12433f max_arch_pfn = 0x400000000 [ 0.000000] e820: last_pfn = 0xdd000 max_arch_pfn = 0x400000000 [ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576 [ 0.000000] reserving inaccessible SNB gfx pages [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff] [ 0.000000] [mem 0x00000000-0x000fffff] page 4k [ 0.000000] init_memory_mapping: [mem 0xdca00000-0xdcbfffff] [ 0.000000] [mem 0xdca00000-0xdcbfffff] page 4k [ 0.000000] BRK [0x01a81000, 0x01a81fff] PGTABLE [ 0.000000] BRK [0x01a82000, 0x01a82fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0xc0000000-0xdb9effff] [ 0.000000] [mem 0xc0000000-0xdb9effff] page 4k [ 0.000000] BRK [0x01a83000, 0x01a83fff] PGTABLE [ 0.000000] BRK [0x01a84000, 0x01a84fff] PGTABLE [ 0.000000] BRK [0x01a85000, 0x01a85fff] PGTABLE [ 0.000000] BRK [0x01a86000, 0x01a86fff] PGTABLE [ 0.000000] init_memory_mapping: [mem 0xdc651000-0xdc651fff] [ 0.000000] [mem 0xdc651000-0xdc651fff] page 4k [ 0.000000] init_memory_mapping: [mem 0xdc695000-0xdc9fffff] [ 0.000000] [mem 0xdc695000-0xdc9fffff] page 4k [ 0.000000] init_memory_mapping: [mem 0xa0000000-0xbfffffff] [ 0.000000] [mem 0xa0000000-0xbfffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff] [ 0.000000] [mem 0x00100000-0x1fffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff] [ 0.000000] [mem 0x20200000-0x3fffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x40200000-0x9fffffff] [ 0.000000] [mem 0x40200000-0x9fffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0xdcc00000-0xdcdb9fff] [ 0.000000] [mem 0xdcc00000-0xdcdb9fff] page 4k [ 0.000000] init_memory_mapping: [mem 0xdcff2000-0xdcffffff] [ 0.000000] [mem 0xdcff2000-0xdcffffff] page 4k [ 0.000000] init_memory_mapping: [mem 0x100000000-0x12433efff] [ 0.000000] [mem 0x100000000-0x12433efff] page 4k [ 0.000000] RAMDISK: [mem 0x04000000-0x048fdfff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000000F0490 000024 (v02 ALASKA) [ 0.000000] ACPI: XSDT 0x00000000DC1E9078 000074 (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: FACP 0x00000000DC1F3710 0000F4 (v04 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: DSDT 0x00000000DC1E9188 00A587 (v02 ALASKA A M I 00000001 INTL 20051117) [ 0.000000] ACPI: FACS 0x00000000DC1F7F80 000040 [ 0.000000] ACPI: APIC 0x00000000DC1F3808 000092 (v03 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: FPDT 0x00000000DC1F38A0 000044 (v01 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: MCFG 0x00000000DC1F38E8 00003C (v01 ALASKA A M I 01072009 MSFT 00000097) [ 0.000000] ACPI: HPET 0x00000000DC1F3928 000038 (v01 ALASKA A M I 01072009 AMI. 00000005) [ 0.000000] ACPI: SSDT 0x00000000DC1F3960 00036D (v01 SataRe SataTabl 00001000 INTL 20091112) [ 0.000000] ACPI: SSDT 0x00000000DC1F3CD0 00081E (v01 PmRef Cpu0Ist 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x00000000DC1F44F0 000A92 (v01 PmRef CpuPm 00003000 INTL 20051117) [ 0.000000] ACPI: XMAR 0x00000000DC1F4F88 0000B0 (v01 INTEL SNB 00000001 INTL 00000001) [ 0.000000] ACPI: ASF! 0x00000000DC1F5038 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] Setting APIC routing to Xen PV. [ 0.000000] NUMA turned off [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000012433efff] [ 0.000000] NODE_DATA(0) allocated [mem 0xdcca2000-0xdcca3fff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.000000] Normal [mem 0x0000000100000000-0x000000012433efff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009cfff] [ 0.000000] node 0: [mem 0x0000000000100000-0x000000001fffffff] [ 0.000000] node 0: [mem 0x0000000020200000-0x000000003fffffff] [ 0.000000] node 0: [mem 0x0000000040200000-0x00000000db9effff] [ 0.000000] node 0: [mem 0x00000000dc651000-0x00000000dc651fff] [ 0.000000] node 0: [mem 0x00000000dc695000-0x00000000dcdb9fff] [ 0.000000] node 0: [mem 0x00000000dcff2000-0x00000000dcffffff] [ 0.000000] node 0: [mem 0x0000000100000000-0x000000012433efff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000012433efff] [ 0.000000] On node 0 totalpages: 1048575 [ 0.000000] DMA zone: 64 pages used for memmap [ 0.000000] DMA zone: 156 pages reserved [ 0.000000] DMA zone: 3996 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 14005 pages used for memmap [ 0.000000] DMA32 zone: 896292 pages, LIFO batch:31 [ 0.000000] Normal zone: 2317 pages used for memmap [ 0.000000] Normal zone: 148287 pages, LIFO batch:31 [ 0.000000] p2m virtual area at ffffc90000000000, size is a00000 [ 0.000000] Remapped 148287 page(s) [ 0.000000] Reserving Intel graphics stolen memory at 0xdda00000-0xdf9fffff [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs [ 0.000000] e820: [mem 0xdfa00000-0xf7ffffff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.5.2 (preserve-AD) [ 0.000000] clocksource refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 29 pages/cpu @ffff880124000000 s81048 r8192 d29544 u262144 [ 0.000000] pcpu-alloc: s81048 r8192 d29544 u262144 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 [ 0.000000] xen: PV spinlocks enabled [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1032033 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: placeholder root=UUID=aeaa7943-af67-42eb-b6f9-e73ebf7296de ro rootflags=subvol=rootfs console=hvc0 earlyprintk=xen i915.modeset=1 xen-pciback.hide=(00:1b.0)(00:1d.0)(01:00.0)(02:00.0)(03:00.0)(04:00.0)(05:00.0)(06:00.0)(08:00.0)(0a:08.0)(0a:09.0)(0a:0a.0)(0a:0b.0) softlevel=xen.d [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form [ 0.000000] software IO TLB [mem 0x120000000-0x124000000] (64MB) mapped at [ffff880120000000-ffff880123ffffff] [ 0.000000] Memory: 4022428K/4194300K available (6464K kernel code, 601K rwdata, 1916K rodata, 1048K init, 652K bss, 171872K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] CONFIG_RCU_FANOUT set to non-default value of 32 [ 0.000000] NR_IRQS:4352 nr_irqs:488 16 [ 0.000000] xen:events: Using FIFO-based ABI [ 0.000000] xen: --> pirq=1 -> irq=1 (gsi=1) [ 0.000000] xen: --> pirq=2 -> irq=2 (gsi=2) [ 0.000000] xen: --> pirq=3 -> irq=3 (gsi=3) [ 0.000000] xen: --> pirq=4 -> irq=4 (gsi=4) [ 0.000000] xen: --> pirq=5 -> irq=5 (gsi=5) [ 0.000000] xen: --> pirq=6 -> irq=6 (gsi=6) [ 0.000000] xen: --> pirq=7 -> irq=7 (gsi=7) [ 0.000000] xen: --> pirq=8 -> irq=8 (gsi=8) [ 0.000000] xen: --> pirq=9 -> irq=9 (gsi=9) [ 0.000000] xen: --> pirq=10 -> irq=10 (gsi=10) [ 0.000000] xen: --> pirq=11 -> irq=11 (gsi=11) [ 0.000000] xen: --> pirq=12 -> irq=12 (gsi=12) [ 0.000000] xen: --> pirq=13 -> irq=13 (gsi=13) [ 0.000000] xen: --> pirq=14 -> irq=14 (gsi=14) [ 0.000000] xen: --> pirq=15 -> irq=15 (gsi=15) [ 0.000000] NO_HZ: Clearing 0 from nohz_full range for timekeeping [ 0.000000] NO_HZ: Full dynticks CPUs: 1-7. [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-7. [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [hvc0] enabled [ 0.000000] bootconsole [xenboot0] disabled [ 0.000000] clocksource xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.000000] Xen: using vcpuop timer interface [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] tsc: Detected 2394.640 MHz processor [ 5.857123] Calibrating delay loop (skipped), value calculated using timer frequency.. 4789.28 BogoMIPS (lpj=23946400) [ 5.857128] pid_max: default: 32768 minimum: 501 [ 5.857137] ACPI: Core revision 20150410 [ 5.882925] ACPI: All ACPI Tables successfully acquired [ 5.883910] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 5.884894] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 5.885262] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 5.885275] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 5.885525] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 5.885529] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 5.885533] CPU: Physical Processor ID: 0 [ 5.885535] CPU: Processor Core ID: 0 [ 5.885539] mce: CPU supports 2 MCE banks [ 5.885553] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [ 5.885555] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [ 5.885978] Freeing SMP alternatives memory: 32K (ffffffff819d5000 - ffffffff819dd000) [ 5.892800] cpu 0 spinlock event irq 25 [ 5.893613] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only. [ 5.893862] installing Xen timer for CPU 1 [ 5.893873] cpu 1 spinlock event irq 32 [ 5.894185] installing Xen timer for CPU 2 [ 5.894195] cpu 2 spinlock event irq 39 [ 5.894487] installing Xen timer for CPU 3 [ 5.894496] cpu 3 spinlock event irq 46 [ 5.894771] installing Xen timer for CPU 4 [ 5.894781] cpu 4 spinlock event irq 53 [ 5.895042] installing Xen timer for CPU 5 [ 5.895051] cpu 5 spinlock event irq 60 [ 5.895290] installing Xen timer for CPU 6 [ 5.895298] cpu 6 spinlock event irq 67 [ 5.895531] installing Xen timer for CPU 7 [ 5.895539] cpu 7 spinlock event irq 74 [ 5.895687] x86: Booted up 1 node, 8 CPUs [ 5.895864] devtmpfs: initialized [ 5.896262] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 5.896325] xor: automatically using best checksumming function: [ 5.987368] avx : 22624.400 MB/sec [ 5.987463] NET: Registered protocol family 16 [ 5.987474] xen:grant_table: Grant tables using version 1 layout [ 5.987483] Grant table initialized [ 5.987765] ACPI: bus type PCI registered [ 5.987898] dca service started, version 1.12.1 [ 5.987923] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 5.987928] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in E820 [ 5.994529] PCI: Using configuration type 1 for base access [ 6.167436] raid6: sse2x1 gen() 6308 MB/s [ 6.337484] raid6: sse2x1 xor() 5051 MB/s [ 6.507550] raid6: sse2x2 gen() 7885 MB/s [ 6.677602] raid6: sse2x2 xor() 5666 MB/s [ 6.847651] raid6: sse2x4 gen() 9175 MB/s [ 7.017703] raid6: sse2x4 xor() 6816 MB/s [ 7.017706] raid6: using algorithm sse2x4 gen() 9175 MB/s [ 7.017709] raid6: .... xor() 6816 MB/s, rmw enabled [ 7.017711] raid6: using ssse3x2 recovery algorithm [ 7.017758] ACPI: Added _OSI(Module Device) [ 7.017764] ACPI: Added _OSI(Processor Device) [ 7.017769] ACPI: Added _OSI(3.0 _SCP Extensions) [ 7.017772] ACPI: Added _OSI(Processor Aggregator Device) [ 7.019223] xen: registering gsi 9 triggering 0 polarity 0 [ 7.020992] ACPI: Executed 1 blocks of module-level executable AML code [ 7.024561] ACPI: Dynamic OEM Table Load: [ 7.024570] ACPI: SSDT 0xFFFF88011FC1D000 00083B (v01 PmRef Cpu0Cst 00003001 INTL 20051117) [ 7.025236] ACPI: Dynamic OEM Table Load: [ 7.025242] ACPI: SSDT 0xFFFF88011F199000 000303 (v01 PmRef ApIst 00003000 INTL 20051117) [ 7.025773] ACPI: Dynamic OEM Table Load: [ 7.025779] ACPI: SSDT 0xFFFF88011F123A00 000119 (v01 PmRef ApCst 00003000 INTL 20051117) [ 7.027766] ACPI: Interpreter enabled [ 7.027773] ACPI: (supports S0 S5) [ 7.027776] ACPI: Using IOAPIC for interrupt routing [ 7.027806] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 7.035495] ACPI: Power Resource [FN00] (off) [ 7.035571] ACPI: Power Resource [FN01] (off) [ 7.035644] ACPI: Power Resource [FN02] (off) [ 7.035717] ACPI: Power Resource [FN03] (off) [ 7.035791] ACPI: Power Resource [FN04] (off) [ 7.036475] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3e]) [ 7.036482] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 7.036835] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug PME] [ 7.037043] acpi PNP0A08:00: _OSC: OS now controls [AER PCIeCapability] [ 7.037422] PCI host bridge to bus 0000:00 [ 7.037427] pci_bus 0000:00: root bus resource [bus 00-3e] [ 7.037430] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] [ 7.037433] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 7.037437] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 7.037440] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window] [ 7.037443] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window] [ 7.037447] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window] [ 7.037451] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window] [ 7.037454] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff window] [ 7.037458] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff window] [ 7.037461] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfeafffff window] [ 7.037476] pci 0000:00:00.0: [8086:0108] type 00 class 0x060000 [ 7.037634] pci 0000:00:01.0: [8086:0101] type 01 class 0x060400 [ 7.037733] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold [ 7.037780] pci 0000:00:01.0: System wakeup disabled by ACPI [ 7.037838] pci 0000:00:01.1: [8086:0105] type 01 class 0x060400 [ 7.037923] pci 0000:00:01.1: PME# supported from D0 D3hot D3cold [ 7.037966] pci 0000:00:01.1: System wakeup disabled by ACPI [ 7.038062] pci 0000:00:02.0: [8086:010a] type 00 class 0x030000 [ 7.038088] pci 0000:00:02.0: reg 0x10: [mem 0xf7400000-0xf77fffff 64bit] [ 7.038106] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] [ 7.038117] pci 0000:00:02.0: reg 0x20: [io 0xf000-0xf03f] [ 7.038284] pci 0000:00:06.0: [8086:010d] type 01 class 0x060400 [ 7.038369] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold [ 7.038413] pci 0000:00:06.0: System wakeup disabled by ACPI [ 7.038492] pci 0000:00:16.0: [8086:1c3a] type 00 class 0x078000 [ 7.038529] pci 0000:00:16.0: reg 0x10: [mem 0xf7f2c000-0xf7f2c00f 64bit] [ 7.038655] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold [ 7.038766] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 [ 7.038795] pci 0000:00:19.0: reg 0x10: [mem 0xf7f00000-0xf7f1ffff] [ 7.038809] pci 0000:00:19.0: reg 0x14: [mem 0xf7f29000-0xf7f29fff] [ 7.038824] pci 0000:00:19.0: reg 0x18: [io 0xf080-0xf09f] [ 7.038931] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 7.038977] pci 0000:00:19.0: System wakeup disabled by ACPI [ 7.039033] pci 0000:00:1a.0: [8086:1c2d] type 00 class 0x0c0320 [ 7.039064] pci 0000:00:1a.0: reg 0x10: [mem 0xf7f28000-0xf7f283ff] [ 7.039207] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold [ 7.039269] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 7.039330] pci 0000:00:1b.0: [8086:1c20] type 00 class 0x040300 [ 7.039360] pci 0000:00:1b.0: reg 0x10: [mem 0xf7f20000-0xf7f23fff 64bit] [ 7.039523] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 7.039570] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 7.039628] pci 0000:00:1c.0: [8086:1c10] type 01 class 0x060400 [ 7.039755] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 7.039788] pci 0000:00:1c.0: Enabling MPC IRBNCE [ 7.039793] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled [ 7.039827] pci 0000:00:1c.0: System wakeup disabled by ACPI [ 7.039890] pci 0000:00:1c.4: [8086:1c18] type 01 class 0x060400 [ 7.040018] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 7.040048] pci 0000:00:1c.4: Enabling MPC IRBNCE [ 7.040053] pci 0000:00:1c.4: Intel PCH root port ACS workaround enabled [ 7.040087] pci 0000:00:1c.4: System wakeup disabled by ACPI [ 7.040149] pci 0000:00:1c.6: [8086:1c1c] type 01 class 0x060400 [ 7.040276] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold [ 7.040306] pci 0000:00:1c.6: Enabling MPC IRBNCE [ 7.040311] pci 0000:00:1c.6: Intel PCH root port ACS workaround enabled [ 7.040345] pci 0000:00:1c.6: System wakeup disabled by ACPI [ 7.040405] pci 0000:00:1d.0: [8086:1c26] type 00 class 0x0c0320 [ 7.040436] pci 0000:00:1d.0: reg 0x10: [mem 0xf7f27000-0xf7f273ff] [ 7.040579] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold [ 7.040642] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 7.040696] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401 [ 7.040855] pci 0000:00:1e.0: System wakeup disabled by ACPI [ 7.040909] pci 0000:00:1f.0: [8086:1c56] type 00 class 0x060100 [ 7.041165] pci 0000:00:1f.2: [8086:1c02] type 00 class 0x010601 [ 7.041195] pci 0000:00:1f.2: reg 0x10: [io 0xf0d0-0xf0d7] [ 7.041209] pci 0000:00:1f.2: reg 0x14: [io 0xf0c0-0xf0c3] [ 7.041223] pci 0000:00:1f.2: reg 0x18: [io 0xf0b0-0xf0b7] [ 7.041238] pci 0000:00:1f.2: reg 0x1c: [io 0xf0a0-0xf0a3] [ 7.041252] pci 0000:00:1f.2: reg 0x20: [io 0xf060-0xf07f] [ 7.041267] pci 0000:00:1f.2: reg 0x24: [mem 0xf7f26000-0xf7f267ff] [ 7.041339] pci 0000:00:1f.2: PME# supported from D3hot [ 7.041429] pci 0000:00:1f.3: [8086:1c22] type 00 class 0x0c0500 [ 7.041457] pci 0000:00:1f.3: reg 0x10: [mem 0xf7f25000-0xf7f250ff 64bit] [ 7.041497] pci 0000:00:1f.3: reg 0x20: [io 0xf040-0xf05f] [ 7.041674] pci 0000:01:00.0: [1000:0072] type 00 class 0x010700 [ 7.041693] pci 0000:01:00.0: reg 0x10: [io 0xe000-0xe0ff] [ 7.041712] pci 0000:01:00.0: reg 0x14: [mem 0xf7ec0000-0xf7ec3fff 64bit] [ 7.041731] pci 0000:01:00.0: reg 0x1c: [mem 0xf7e80000-0xf7ebffff 64bit] [ 7.041755] pci 0000:01:00.0: reg 0x30: [mem 0xf7e00000-0xf7e7ffff pref] [ 7.041820] pci 0000:01:00.0: supports D1 D2 [ 7.057784] pci 0000:00:01.0: PCI bridge to [bus 01] [ 7.057793] pci 0000:00:01.0: bridge window [io 0xe000-0xefff] [ 7.057798] pci 0000:00:01.0: bridge window [mem 0xf7e00000-0xf7efffff] [ 7.057883] pci 0000:02:00.0: [1b21:1080] type 01 class 0x060400 [ 7.058029] pci 0000:02:00.0: supports D1 D2 [ 7.058030] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 7.077819] pci 0000:00:01.1: PCI bridge to [bus 02-03] [ 7.077831] pci 0000:00:01.1: bridge window [mem 0xf7d00000-0xf7dfffff] [ 7.077924] pci 0000:03:00.0: [1b74:0100] type 00 class 0xff0000 [ 7.077951] pci 0000:03:00.0: reg 0x10: [mem 0xf7d00000-0xf7d0ffff] [ 7.078199] pci 0000:02:00.0: PCI bridge to [bus 03] [ 7.078216] pci 0000:02:00.0: bridge window [mem 0xf7d00000-0xf7dfffff] [ 7.078338] pci 0000:04:00.0: [168c:0030] type 00 class 0x028000 [ 7.078369] pci 0000:04:00.0: reg 0x10: [mem 0xf7c00000-0xf7c1ffff 64bit] [ 7.078438] pci 0000:04:00.0: reg 0x30: [mem 0xf7c20000-0xf7c2ffff pref] [ 7.078505] pci 0000:04:00.0: supports D1 [ 7.078507] pci 0000:04:00.0: PME# supported from D0 D1 D3hot [ 7.097851] pci 0000:00:06.0: PCI bridge to [bus 04] [ 7.097862] pci 0000:00:06.0: bridge window [mem 0xf7c00000-0xf7cfffff] [ 7.097977] pci 0000:05:00.0: [10b5:8112] type 01 class 0x060400 [ 7.098210] pci 0000:05:00.0: supports D1 [ 7.098212] pci 0000:05:00.0: PME# supported from D0 D1 D3hot [ 7.098251] pci 0000:05:00.0: System wakeup disabled by ACPI [ 7.098309] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [ 7.098329] pci 0000:00:1c.0: PCI bridge to [bus 05-06] [ 7.098340] pci 0000:00:1c.0: bridge window [mem 0xf7b00000-0xf7bfffff] [ 7.098446] pci 0000:06:00.0: [1b74:0810] type 00 class 0x078000 [ 7.098484] pci 0000:06:00.0: reg 0x10: [mem 0xf7b00000-0xf7b7ffff] [ 7.098864] pci 0000:05:00.0: PCI bridge to [bus 06] [ 7.098881] pci 0000:05:00.0: bridge window [mem 0xf7b00000-0xf7bfffff] [ 7.099005] pci 0000:07:00.0: [8086:10d3] type 00 class 0x020000 [ 7.099082] pci 0000:07:00.0: reg 0x10: [mem 0xf7a40000-0xf7a5ffff] [ 7.099133] pci 0000:07:00.0: reg 0x18: [io 0xd000-0xd01f] [ 7.099159] pci 0000:07:00.0: reg 0x1c: [mem 0xf7a60000-0xf7a63fff] [ 7.099234] pci 0000:07:00.0: reg 0x30: [mem 0xf7a00000-0xf7a3ffff pref] [ 7.099370] pci 0000:07:00.0: PME# supported from D0 D3hot D3cold [ 7.099411] pci 0000:07:00.0: System wakeup disabled by ACPI [ 7.117941] pci 0000:00:1c.4: PCI bridge to [bus 07] [ 7.117952] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] [ 7.117958] pci 0000:00:1c.4: bridge window [mem 0xf7a00000-0xf7afffff] [ 7.118069] pci 0000:08:00.0: [1033:0194] type 00 class 0x0c0330 [ 7.118113] pci 0000:08:00.0: reg 0x10: [mem 0xf7900000-0xf7901fff 64bit] [ 7.118325] pci 0000:08:00.0: PME# supported from D0 D3hot [ 7.118365] pci 0000:08:00.0: System wakeup disabled by ACPI [ 7.118498] pci 0000:00:1c.6: PCI bridge to [bus 08] [ 7.118509] pci 0000:00:1c.6: bridge window [mem 0xf7900000-0xf79fffff] [ 7.118576] pci 0000:09:00.0: [12d8:8148] type 01 class 0x060400 [ 7.118707] pci 0000:09:00.0: supports D1 D2 [ 7.118826] pci 0000:00:1e.0: PCI bridge to [bus 09-0a] (subtractive decode) [ 7.118834] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] [ 7.118839] pci 0000:00:1e.0: bridge window [mem 0xf7800000-0xf78fffff] [ 7.118849] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7 window] (subtractive decode) [ 7.118850] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff window] (subtractive decode) [ 7.118852] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode) [ 7.118854] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000d3fff window] (subtractive decode) [ 7.118855] pci 0000:00:1e.0: bridge window [mem 0x000d4000-0x000d7fff window] (subtractive decode) [ 7.118857] pci 0000:00:1e.0: bridge window [mem 0x000d8000-0x000dbfff window] (subtractive decode) [ 7.118859] pci 0000:00:1e.0: bridge window [mem 0x000dc000-0x000dffff window] (subtractive decode) [ 7.118860] pci 0000:00:1e.0: bridge window [mem 0x000e0000-0x000e3fff window] (subtractive decode) [ 7.118862] pci 0000:00:1e.0: bridge window [mem 0x000e4000-0x000e7fff window] (subtractive decode) [ 7.118863] pci 0000:00:1e.0: bridge window [mem 0xdfa00000-0xfeafffff window] (subtractive decode) [ 7.118957] pci 0000:0a:08.0: [10ec:8139] type 00 class 0x020000 [ 7.118993] pci 0000:0a:08.0: reg 0x10: [io 0xc200-0xc2ff] [ 7.119014] pci 0000:0a:08.0: reg 0x14: [mem 0xf7842000-0xf78420ff] [ 7.119114] pci 0000:0a:08.0: reg 0x30: [mem 0xf7830000-0xf783ffff pref] [ 7.119169] pci 0000:0a:08.0: supports D1 D2 [ 7.119171] pci 0000:0a:08.0: PME# supported from D1 D2 D3hot D3cold [ 7.119244] pci 0000:0a:09.0: [10ec:8139] type 00 class 0x020000 [ 7.119279] pci 0000:0a:09.0: reg 0x10: [io 0xc100-0xc1ff] [ 7.119301] pci 0000:0a:09.0: reg 0x14: [mem 0xf7841000-0xf78410ff] [ 7.119400] pci 0000:0a:09.0: reg 0x30: [mem 0xf7820000-0xf782ffff pref] [ 7.119455] pci 0000:0a:09.0: supports D1 D2 [ 7.119457] pci 0000:0a:09.0: PME# supported from D1 D2 D3hot D3cold [ 7.119528] pci 0000:0a:0a.0: [10ec:8139] type 00 class 0x020000 [ 7.119564] pci 0000:0a:0a.0: reg 0x10: [io 0xc000-0xc0ff] [ 7.119585] pci 0000:0a:0a.0: reg 0x14: [mem 0xf7840000-0xf78400ff] [ 7.119685] pci 0000:0a:0a.0: reg 0x30: [mem 0xf7810000-0xf781ffff pref] [ 7.119740] pci 0000:0a:0a.0: supports D1 D2 [ 7.119741] pci 0000:0a:0a.0: PME# supported from D1 D2 D3hot D3cold [ 7.119814] pci 0000:0a:0b.0: [168c:0029] type 00 class 0x028000 [ 7.119885] pci 0000:0a:0b.0: reg 0x10: [mem 0xf7800000-0xf780ffff] [ 7.120058] pci 0000:0a:0b.0: PME# supported from D0 D3hot [ 7.120167] pci 0000:09:00.0: PCI bridge to [bus 0a] [ 7.120180] pci 0000:09:00.0: bridge window [io 0xc000-0xcfff] [ 7.120186] pci 0000:09:00.0: bridge window [mem 0xf7800000-0xf78fffff] [ 7.121200] xen: registering gsi 13 triggering 1 polarity 0 [ 7.121416] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 *14 15) [ 7.121484] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 *15) [ 7.121549] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 10 11 12 14 15) [ 7.121614] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 10 11 12 14 15) [ 7.121679] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 *14 15) [ 7.121742] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled. [ 7.121808] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 *15) [ 7.121872] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 *14 15) [ 7.122093] ACPI: Enabled 4 GPEs in block 00 to 3F [ 7.122131] xen:balloon: Initialising balloon driver [ 7.122282] xen_balloon: Initialising balloon driver [ 7.122407] vgaarb: setting as boot device: PCI:0000:00:02.0 [ 7.122411] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 7.122417] vgaarb: loaded [ 7.122419] vgaarb: bridge control possible 0000:00:02.0 [ 7.122478] SCSI subsystem initialized [ 7.122490] libata version 3.00 loaded. [ 7.122493] ACPI: bus type USB registered [ 7.122511] usbcore: registered new interface driver usbfs [ 7.122521] usbcore: registered new interface driver hub [ 7.122546] usbcore: registered new device driver usb [ 7.122572] pps_core: LinuxPPS API ver. 1 registered [ 7.122574] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 7.122581] PTP clock support registered [ 7.122744] PCI: Using ACPI for IRQ routing [ 7.125846] PCI: pci_cache_line_size set to 64 bytes [ 7.125989] e820: reserve RAM buffer [mem 0x0009d000-0x0009ffff] [ 7.125991] e820: reserve RAM buffer [mem 0xdb9f0000-0xdbffffff] [ 7.125992] e820: reserve RAM buffer [mem 0xdc652000-0xdfffffff] [ 7.125994] e820: reserve RAM buffer [mem 0xdcdba000-0xdfffffff] [ 7.125996] e820: reserve RAM buffer [mem 0xdd000000-0xdfffffff] [ 7.125997] e820: reserve RAM buffer [mem 0x12433f000-0x127ffffff] [ 7.126196] Switched to clocksource xen [ 7.126334] pnp: PnP ACPI init [ 7.126412] system 00:00: [mem 0xfed40000-0xfed44fff] has been reserved [ 7.126417] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) [ 7.126491] system 00:01: [io 0x0680-0x069f] has been reserved [ 7.126495] system 00:01: [io 0x1000-0x100f] has been reserved [ 7.126498] system 00:01: [io 0xffff] has been reserved [ 7.126501] system 00:01: [io 0xffff] has been reserved [ 7.126504] system 00:01: [io 0x0400-0x0453] could not be reserved [ 7.126508] system 00:01: [io 0x0458-0x047f] has been reserved [ 7.126511] system 00:01: [io 0x0500-0x057f] has been reserved [ 7.126514] system 00:01: [io 0x164e-0x164f] has been reserved [ 7.126518] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 7.126525] xen: registering gsi 8 triggering 1 polarity 0 [ 7.126554] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) [ 7.126600] system 00:03: [io 0x0454-0x0457] has been reserved [ 7.126604] system 00:03: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active) [ 7.126768] system 00:04: [io 0x0a00-0x0a0f] has been reserved [ 7.126772] system 00:04: [io 0x0a10-0x0a1f] has been reserved [ 7.126805] system 00:04: [io 0x0a10-0x0a1f] has been reserved [ 7.126808] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 7.126829] xen: registering gsi 1 triggering 1 polarity 0 [ 7.126863] pnp 00:05: Plug and Play ACPI device, IDs PNP0303 PNP030b (active) [ 7.127155] ACPI: IRQ 4 override to edge, high [ 7.127158] xen: registering gsi 4 triggering 1 polarity 0 [ 7.127160] Already setup the GSI :4 [ 7.127207] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active) [ 7.127808] system 00:07: [io 0x04d0-0x04d1] has been reserved [ 7.127813] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active) [ 7.128070] system 00:08: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 7.128074] system 00:08: [mem 0xfed10000-0xfed17fff] has been reserved [ 7.128077] system 00:08: [mem 0xfed18000-0xfed18fff] has been reserved [ 7.128081] system 00:08: [mem 0xfed19000-0xfed19fff] has been reserved [ 7.128084] system 00:08: [mem 0xf8000000-0xfbffffff] has been reserved [ 7.128087] system 00:08: [mem 0xfed20000-0xfed3ffff] has been reserved [ 7.128091] system 00:08: [mem 0xfed90000-0xfed93fff] could not be reserved [ 7.128094] system 00:08: [mem 0xfed45000-0xfed8ffff] has been reserved [ 7.128098] system 00:08: [mem 0xff000000-0xffffffff] has been reserved [ 7.128101] system 00:08: [mem 0xfee00000-0xfeefffff] has been reserved [ 7.128104] system 00:08: [mem 0xdfa00000-0xdfa00fff] has been reserved [ 7.128108] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active) [ 7.128274] system 00:09: [mem 0x20000000-0x201fffff] has been reserved [ 7.128277] system 00:09: [mem 0x40000000-0x401fffff] has been reserved [ 7.128281] system 00:09: Plug and Play ACPI device, IDs PNP0c01 (active) [ 7.128297] pnp: PnP ACPI: found 10 devices [ 7.128333] pciback 0000:00:1b.0: seizing device [ 7.128345] pciback 0000:00:1d.0: seizing device [ 7.128360] pciback 0000:01:00.0: seizing device [ 7.128365] pciback 0000:02:00.0: seizing device [ 7.128370] pciback 0000:03:00.0: seizing device [ 7.128374] pciback 0000:04:00.0: seizing device [ 7.128379] pciback 0000:05:00.0: seizing device [ 7.128383] pciback 0000:06:00.0: seizing device [ 7.128390] pciback 0000:08:00.0: seizing device [ 7.128397] pciback 0000:0a:08.0: seizing device [ 7.128403] pciback 0000:0a:09.0: seizing device [ 7.128408] pciback 0000:0a:0a.0: seizing device [ 7.128412] pciback 0000:0a:0b.0: seizing device [ 7.135752] PM-Timer failed consistency check (0xffffff) - aborting. [ 7.135875] pci 0000:00:01.0: PCI bridge to [bus 01] [ 7.135880] pci 0000:00:01.0: bridge window [io 0xe000-0xefff] [ 7.135888] pci 0000:00:01.0: bridge window [mem 0xf7e00000-0xf7efffff] [ 7.135899] pciback 0000:02:00.0: PCI bridge to [bus 03] [ 7.135909] pciback 0000:02:00.0: bridge window [mem 0xf7d00000-0xf7dfffff] [ 7.135925] pci 0000:00:01.1: PCI bridge to [bus 02-03] [ 7.135931] pci 0000:00:01.1: bridge window [mem 0xf7d00000-0xf7dfffff] [ 7.135943] pci 0000:00:06.0: PCI bridge to [bus 04] [ 7.135949] pci 0000:00:06.0: bridge window [mem 0xf7c00000-0xf7cfffff] [ 7.135960] pciback 0000:05:00.0: PCI bridge to [bus 06] [ 7.135974] pciback 0000:05:00.0: bridge window [mem 0xf7b00000-0xf7bfffff] [ 7.135999] pci 0000:00:1c.0: PCI bridge to [bus 05-06] [ 7.136008] pci 0000:00:1c.0: bridge window [mem 0xf7b00000-0xf7bfffff] [ 7.136023] pci 0000:00:1c.4: PCI bridge to [bus 07] [ 7.136027] pci 0000:00:1c.4: bridge window [io 0xd000-0xdfff] [ 7.136036] pci 0000:00:1c.4: bridge window [mem 0xf7a00000-0xf7afffff] [ 7.136051] pci 0000:00:1c.6: PCI bridge to [bus 08] [ 7.136060] pci 0000:00:1c.6: bridge window [mem 0xf7900000-0xf79fffff] [ 7.136075] pci 0000:09:00.0: PCI bridge to [bus 0a] [ 7.136080] pci 0000:09:00.0: bridge window [io 0xc000-0xcfff] [ 7.136090] pci 0000:09:00.0: bridge window [mem 0xf7800000-0xf78fffff] [ 7.136106] pci 0000:00:1e.0: PCI bridge to [bus 09-0a] [ 7.136111] pci 0000:00:1e.0: bridge window [io 0xc000-0xcfff] [ 7.136120] pci 0000:00:1e.0: bridge window [mem 0xf7800000-0xf78fffff] [ 7.136134] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] [ 7.136136] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] [ 7.136138] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] [ 7.136140] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff window] [ 7.136141] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff window] [ 7.136143] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff window] [ 7.136145] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff window] [ 7.136146] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff window] [ 7.136148] pci_bus 0000:00: resource 12 [mem 0x000e4000-0x000e7fff window] [ 7.136150] pci_bus 0000:00: resource 13 [mem 0xdfa00000-0xfeafffff window] [ 7.136151] pci_bus 0000:01: resource 0 [io 0xe000-0xefff] [ 7.136153] pci_bus 0000:01: resource 1 [mem 0xf7e00000-0xf7efffff] [ 7.136155] pci_bus 0000:02: resource 1 [mem 0xf7d00000-0xf7dfffff] [ 7.136156] pci_bus 0000:03: resource 1 [mem 0xf7d00000-0xf7dfffff] [ 7.136158] pci_bus 0000:04: resource 1 [mem 0xf7c00000-0xf7cfffff] [ 7.136160] pci_bus 0000:05: resource 1 [mem 0xf7b00000-0xf7bfffff] [ 7.136161] pci_bus 0000:06: resource 1 [mem 0xf7b00000-0xf7bfffff] [ 7.136163] pci_bus 0000:07: resource 0 [io 0xd000-0xdfff] [ 7.136165] pci_bus 0000:07: resource 1 [mem 0xf7a00000-0xf7afffff] [ 7.136166] pci_bus 0000:08: resource 1 [mem 0xf7900000-0xf79fffff] [ 7.136168] pci_bus 0000:09: resource 0 [io 0xc000-0xcfff] [ 7.136169] pci_bus 0000:09: resource 1 [mem 0xf7800000-0xf78fffff] [ 7.136171] pci_bus 0000:09: resource 4 [io 0x0000-0x0cf7 window] [ 7.136173] pci_bus 0000:09: resource 5 [io 0x0d00-0xffff window] [ 7.136174] pci_bus 0000:09: resource 6 [mem 0x000a0000-0x000bffff window] [ 7.136176] pci_bus 0000:09: resource 7 [mem 0x000d0000-0x000d3fff window] [ 7.136178] pci_bus 0000:09: resource 8 [mem 0x000d4000-0x000d7fff window] [ 7.136179] pci_bus 0000:09: resource 9 [mem 0x000d8000-0x000dbfff window] [ 7.136181] pci_bus 0000:09: resource 10 [mem 0x000dc000-0x000dffff window] [ 7.136192] pci_bus 0000:09: resource 11 [mem 0x000e0000-0x000e3fff window] [ 7.136194] pci_bus 0000:09: resource 12 [mem 0x000e4000-0x000e7fff window] [ 7.136196] pci_bus 0000:09: resource 13 [mem 0xdfa00000-0xfeafffff window] [ 7.136198] pci_bus 0000:0a: resource 0 [io 0xc000-0xcfff] [ 7.136199] pci_bus 0000:0a: resource 1 [mem 0xf7800000-0xf78fffff] [ 7.136223] NET: Registered protocol family 2 [ 7.136371] TCP established hash table entries: 32768 (order: 6, 262144 bytes) [ 7.136487] TCP bind hash table entries: 32768 (order: 7, 524288 bytes) [ 7.136555] TCP: Hash tables configured (established 32768 bind 32768) [ 7.136584] UDP hash table entries: 2048 (order: 4, 65536 bytes) [ 7.136607] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes) [ 7.136649] NET: Registered protocol family 1 [ 7.136750] RPC: Registered named UNIX socket transport module. [ 7.136753] RPC: Registered udp transport module. [ 7.136756] RPC: Registered tcp transport module. [ 7.136758] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 7.137220] pci 0000:00:02.0: BIOS left Intel GPU interrupts enabled; disabling [ 7.137976] pci 0000:00:02.0: Video device with shadowed ROM [ 7.138063] xen: registering gsi 16 triggering 0 polarity 1 [ 7.138073] xen: --> pirq=16 -> irq=16 (gsi=16) [ 7.156353] xen: registering gsi 23 triggering 0 polarity 1 [ 7.156361] xen: --> pirq=23 -> irq=23 (gsi=23) [ 7.176384] PCI: CLS mismatch (64 != 32), using 64 bytes [ 7.176455] xen: registering gsi 18 triggering 0 polarity 1 [ 7.176464] xen: --> pirq=18 -> irq=18 (gsi=18) [ 7.176511] xen: registering gsi 18 triggering 0 polarity 1 [ 7.176513] Already setup the GSI :18 [ 7.176628] Unpacking initramfs... [ 7.181511] Freeing initrd memory: 9208K (ffff880004000000 - ffff8800048fe000) [ 7.181617] RAPL PMU detected, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 7.181621] hw unit of domain pp0-core 2^-16 Joules [ 7.181623] hw unit of domain package 2^-16 Joules [ 7.181626] hw unit of domain pp1-gpu 2^-16 Joules [ 7.182865] AVX version of gcm_enc/dec engaged. [ 7.182870] AES CTR mode by8 optimization enabled [ 7.183733] futex hash table entries: 2048 (order: 5, 131072 bytes) [ 7.183901] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 7.185768] zpool: loaded [ 7.185772] zbud: loaded [ 7.186507] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 7.186727] NFS: Registering the id_resolver key type [ 7.186737] Key type id_resolver registered [ 7.186740] Key type id_legacy registered [ 7.186744] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 7.187105] async_tx: api initialized (async) [ 7.187139] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250) [ 7.187144] io scheduler noop registered [ 7.187186] io scheduler cfq registered (default) [ 7.187346] xen: registering gsi 16 triggering 0 polarity 1 [ 7.187350] Already setup the GSI :16 [ 7.187532] xen: registering gsi 16 triggering 0 polarity 1 [ 7.187534] Already setup the GSI :16 [ 7.187690] xen: registering gsi 19 triggering 0 polarity 1 [ 7.187699] xen: --> pirq=19 -> irq=19 (gsi=19) [ 7.187864] xen: registering gsi 16 triggering 0 polarity 1 [ 7.187866] Already setup the GSI :16 [ 7.187997] xen: registering gsi 16 triggering 0 polarity 1 [ 7.187998] Already setup the GSI :16 [ 7.188168] intel_idle: MWAIT substates: 0x1120 [ 7.188170] intel_idle: v0.4 model 0x2A [ 7.188171] intel_idle: lapic_timer_reliable_states 0xffffffff [ 7.188222] intel_idle: intel_idle yielding to none [ 7.188228] ioatdma: Intel(R) QuickData Technology Driver 4.00 [ 7.188392] xen:xen_evtchn: Event-channel device installed [ 7.188658] xen: registering gsi 19 triggering 0 polarity 1 [ 7.188660] Already setup the GSI :19 [ 7.236394] xen: registering gsi 18 triggering 0 polarity 1 [ 7.236398] Already setup the GSI :18 [ 7.276402] xen: registering gsi 17 triggering 0 polarity 1 [ 7.276413] xen: --> pirq=17 -> irq=17 (gsi=17) [ 7.316413] xen: registering gsi 16 triggering 0 polarity 1 [ 7.316417] Already setup the GSI :16 [ 7.356411] xen: registering gsi 18 triggering 0 polarity 1 [ 7.356414] Already setup the GSI :18 [ 8.176258] clocksource tsc: mask: 0xffffffffffffffff max_cycles: 0x22847025dca, max_idle_ns: 440795321856 ns [ 8.386463] xen: registering gsi 16 triggering 0 polarity 1 [ 8.386467] Already setup the GSI :16 [ 8.386506] xen: registering gsi 16 triggering 0 polarity 1 [ 8.386508] Already setup the GSI :16 [ 9.176558] Switched to clocksource tsc [ 9.456419] xen: registering gsi 19 triggering 0 polarity 1 [ 9.456422] Already setup the GSI :19 [ 9.496408] xen: registering gsi 17 triggering 0 polarity 1 [ 9.496412] Already setup the GSI :17 [ 9.496445] xen: registering gsi 17 triggering 0 polarity 1 [ 9.496447] Already setup the GSI :17 [ 10.526605] xen: registering gsi 16 triggering 0 polarity 1 [ 10.526608] Already setup the GSI :16 [ 10.636527] xen: registering gsi 23 triggering 0 polarity 1 [ 10.636531] Already setup the GSI :23 [ 10.746540] xen: registering gsi 22 triggering 0 polarity 1 [ 10.746550] xen: --> pirq=22 -> irq=22 (gsi=22) [ 10.856528] xen_pciback: backend is vpci [ 10.861420] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 10.861873] hpet_acpi_add: no address or irqs in _CRS [ 10.861902] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [ 10.863363] loop: module loaded [ 10.863477] zram: Created 1 device(s) [ 10.863576] xen: registering gsi 16 triggering 0 polarity 1 [ 10.863579] Already setup the GSI :16 [ 10.869720] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20150410/utaddress-254) [ 10.869730] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.869736] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254) [ 10.869742] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.869746] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254) [ 10.869752] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.869755] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254) [ 10.869762] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.869766] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 10.869830] ahci 0000:00:1f.2: version 3.0 [ 10.869903] xen: registering gsi 19 triggering 0 polarity 1 [ 10.869906] Already setup the GSI :19 [ 10.886312] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x3f impl SATA mode [ 10.886317] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part ems apst [ 10.986935] scsi host0: ahci [ 10.987191] scsi host1: ahci [ 10.987313] scsi host2: ahci [ 10.987424] scsi host3: ahci [ 10.987531] scsi host4: ahci [ 10.987635] scsi host5: ahci [ 10.987671] ata1: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26100 irq 88 [ 10.987676] ata2: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26180 irq 88 [ 10.987679] ata3: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26200 irq 88 [ 10.987683] ata4: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26280 irq 88 [ 10.987687] ata5: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26300 irq 88 [ 10.987690] ata6: SATA max UDMA/133 abar m2048@0xf7f26000 port 0xf7f26380 irq 88 [ 10.987724] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [ 10.987728] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. [ 10.987833] xen: registering gsi 20 triggering 0 polarity 1 [ 10.987843] xen: --> pirq=20 -> irq=20 (gsi=20) [ 10.987961] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 11.192428] e1000e 0000:00:19.0 eth0: registered PHC clock [ 11.192433] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:18:7d:1d:72:74 [ 11.192437] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection [ 11.192480] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF [ 11.192543] xen: registering gsi 16 triggering 0 polarity 1 [ 11.192545] Already setup the GSI :16 [ 11.192742] e1000e 0000:07:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 11.310330] e1000e 0000:07:00.0 eth1: registered PHC clock [ 11.310336] e1000e 0000:07:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:18:7d:1d:71:de [ 11.310340] e1000e 0000:07:00.0 eth1: Intel(R) PRO/1000 Network Connection [ 11.310431] e1000e 0000:07:00.0 eth1: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF [ 11.310463] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 11.310468] ehci-pci: EHCI PCI platform driver [ 11.310555] xen: registering gsi 16 triggering 0 polarity 1 [ 11.310557] Already setup the GSI :16 [ 11.310593] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 11.310600] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 [ 11.310619] ehci-pci 0000:00:1a.0: debug port 2 [ 11.314579] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported [ 11.314617] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf7f28000 [ 11.326295] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 11.326478] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 11.326484] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 11.326488] usb usb1: Product: EHCI Host Controller [ 11.326490] usb usb1: Manufacturer: Linux 4.1.7-hardened-r1 ehci_hcd [ 11.326493] usb usb1: SerialNumber: 0000:00:1a.0 [ 11.326639] hub 1-0:1.0: USB hub found [ 11.326661] hub 1-0:1.0: 2 ports detected [ 11.326933] usbcore: registered new interface driver usbserial [ 11.326953] usbcore: registered new interface driver ftdi_sio [ 11.326963] usbserial: USB Serial support registered for FTDI USB Serial Device [ 11.326997] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1 [ 11.327000] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 11.327172] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 11.327346] mousedev: PS/2 mouse device common for all mice [ 11.327394] rtc_cmos 00:02: RTC can wake from S4 [ 11.327628] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 [ 11.327689] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram [ 11.327899] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 11.327922] iTCO_wdt: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [ 11.328058] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 11.328074] md: raid1 personality registered for level 1 [ 11.328079] md: raid10 personality registered for level 10 [ 11.328234] md: raid6 personality registered for level 6 [ 11.328238] md: raid5 personality registered for level 5 [ 11.328241] md: raid4 personality registered for level 4 [ 11.328331] device-mapper: uevent: version 1.0.3 [ 11.328489] device-mapper: ioctl: 4.31.0-ioctl (2015-3-12) initialised: dm-devel@redhat.com [ 11.328498] device-mapper: raid: Loading target version 1.6.0 [ 11.328519] hidraw: raw HID events driver (C) Jiri Kosina [ 11.328655] NET: Registered protocol family 17 [ 11.328677] Key type dns_resolver registered [ 11.328863] mce: Unable to init device /dev/mcelog (rc: -16) [ 11.329351] registered taskstats version 1 [ 11.329910] Btrfs loaded [ 11.330651] rtc_cmos 00:02: setting system clock to 2015-11-15 23:53:36 UTC (1447631616) [ 11.336299] ata5: SATA link down (SStatus 0 SControl 300) [ 11.336332] ata3: SATA link down (SStatus 0 SControl 300) [ 11.336354] ata4: SATA link down (SStatus 0 SControl 300) [ 11.336375] ata6: SATA link down (SStatus 0 SControl 300) [ 11.346342] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.346365] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.346413] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [ 11.347957] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 11.347962] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 11.347970] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 11.348276] ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 11.348279] ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 11.348285] ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 11.349605] ata1.00: ATA-8: WDC WD1003FBYZ-010FB0, 01.01V03, max UDMA/133 [ 11.349611] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 11.349912] ata2.00: ATA-8: WDC WD1003FBYZ-010FB0, 01.01V03, max UDMA/133 [ 11.349915] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA [ 11.351161] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 11.351164] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 11.351171] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 11.351736] ata2.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 11.351740] ata2.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 11.351746] ata2.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 11.352530] ata1.00: configured for UDMA/133 [ 11.352700] scsi 0:0:0:0: Direct-Access ATA WDC WD1003FBYZ-0 1V03 PQ: 0 ANSI: 5 [ 11.352930] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [ 11.353096] sd 0:0:0:0: [sda] Write Protect is off [ 11.353102] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 11.353147] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.354189] ata2.00: configured for UDMA/133 [ 11.354304] scsi 1:0:0:0: Direct-Access ATA WDC WD1003FBYZ-0 1V03 PQ: 0 ANSI: 5 [ 11.354541] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [ 11.354655] sd 1:0:0:0: [sdb] Write Protect is off [ 11.354660] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 11.354693] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 11.399691] sda: sda1 sda2 sda3 sda4 sda5 [ 11.400298] sd 0:0:0:0: [sda] Attached SCSI disk [ 11.402760] sdb: sdb1 sdb2 sdb3 sdb4 sdb5 [ 11.403436] sd 1:0:0:0: [sdb] Attached SCSI disk [ 11.403838] Freeing unused kernel memory: 1048K (ffffffff818cf000 - ffffffff819d5000) [ 11.644555] BTRFS: device label root devid 1 transid 926982 /dev/sdb4 [ 11.644694] BTRFS: device label root devid 3 transid 926982 /dev/sda4 [ 11.646312] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 11.647928] md: md1 stopped. [ 11.648542] md: bind<sda2> [ 11.648696] md: bind<sdb2> [ 11.649038] md/raid1:md1: active with 2 out of 2 mirrors [ 11.649058] md1: detected capacity change from 0 to 1073676288 [ 11.652270] md: md2 stopped. [ 11.652850] md: bind<sda3> [ 11.652998] md: bind<sdb3> [ 11.653311] md/raid1:md2: active with 2 out of 2 mirrors [ 11.653328] md2: detected capacity change from 0 to 17179803648 [ 11.656723] md: md3 stopped. [ 11.657316] md: bind<sda5> [ 11.657462] md: bind<sdb5> [ 11.657736] md/raid1:md3: active with 2 out of 2 mirrors [ 11.657753] md3: detected capacity change from 0 to 844374736896 [ 11.797013] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [ 11.797016] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 11.797416] hub 1-1:1.0: USB hub found [ 11.797593] hub 1-1:1.0: 6 ports detected [ 11.977886] BTRFS info (device sda4): enabling auto defrag [ 11.977889] BTRFS info (device sda4): disk space caching is enabled [ 12.002584] random: nonblocking pool is initialized [ 12.076342] usb 1-1.6: new full-speed USB device number 3 using ehci-pci [ 12.195822] usb 1-1.6: New USB device found, idVendor=0403, idProduct=fc0d [ 12.195825] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 12.195827] usb 1-1.6: Product: Crystalfontz CFA635-USB LCD [ 12.195829] usb 1-1.6: Manufacturer: Crystalfontz [ 12.195830] usb 1-1.6: SerialNumber: CF004445 [ 12.199835] ftdi_sio 1-1.6:1.0: FTDI USB Serial Device converter detected [ 12.199855] usb 1-1.6: Detected FT232RL [ 12.200420] usb 1-1.6: FTDI USB Serial Device converter now attached to ttyUSB0 [ 15.473634] udevd[322]: starting version 3.1.2 [ 16.242876] Monitor-Mwait will be used to enter C-1 state [ 16.242905] Monitor-Mwait will be used to enter C-2 state [ 16.242927] Monitor-Mwait will be used to enter C-3 state [ 16.244799] Warning: Processor Platform Limit not supported. [ 16.263178] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1 [ 16.263183] ACPI: Power Button [PWRB] [ 16.263226] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 16.263228] ACPI: Power Button [PWRF] [ 16.286497] EDAC MC: Ver: 3.0.0 [ 16.300701] Linux agpgart interface v0.103 [ 16.303254] e1000e 0000:00:19.0 enp0s25: renamed from eth0 [ 16.320396] xen: registering gsi 18 triggering 0 polarity 1 [ 16.320402] Already setup the GSI :18 [ 16.320410] ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150410/utaddress-254) [ 16.320416] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 16.329659] thermal LNXTHERM:00: registered as thermal_zone0 [ 16.329662] ACPI: Thermal Zone [TZ00] (28 C) [ 16.329962] thermal LNXTHERM:01: registered as thermal_zone1 [ 16.329964] ACPI: Thermal Zone [TZ01] (30 C) [ 16.376579] e1000e 0000:07:00.0 enp7s0: renamed from eth1 [ 16.396998] EDAC MC0: Giving out device to module ie31200_edac controller IE31200: DEV 0000:00:00.0 (POLLED) [ 16.397477] [drm] Initialized drm 1.1.0 20060810 [ 16.474564] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 17.064042] xen: registering gsi 16 triggering 0 polarity 1 [ 17.064048] Already setup the GSI :16 [ 17.064949] [drm] Memory usable by graphics device = 2048M [ 17.064951] [drm] Replacing VGA console driver [ 17.065495] Console: switching to colour dummy device 128x54 [ 17.097700] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 17.097702] [drm] Driver supports precise vblank timestamp query. [ 17.097854] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 17.101748] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 17.102011] acpi device:49: registered as cooling_device13 [ 17.102116] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 [ 17.102153] [drm] Initialized i915 1.6.0 20150327 for 0000:00:02.0 on minor 0 [ 17.126051] fbcon: inteldrmfb (fb0) is primary device [ 17.172350] Console: switching to colour frame buffer device 128x48 [ 17.174173] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 17.174175] i915 0000:00:02.0: registered panic notifier [ 20.318348] device-mapper: thin: Data device (dm-25) discard unsupported: Disabling discard passdown. [ 21.699375] Adding 16777148k swap on /dev/md2. Priority:-1 extents:1 across:16777148k FS [ 21.758189] EXT4-fs (dm-1): mounted filesystem without journal. Opts: (null) [ 24.396665] Ebtables v2.0 registered [ 24.592180] NET: Registered protocol family 10 [ 24.604096] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 24.695803] ip_tables: (C) 2000-2006 Netfilter Core Team [ 24.784627] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 24.792045] Bridge firewalling registered [ 25.187015] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready [ 25.673933] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready [ 26.129998] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) [ 26.141869] bond0: Setting MII monitoring interval to 100 [ 26.282823] e1000e: enp0s25 NIC Link is Down [ 26.370699] e1000e: enp7s0 NIC Link is Down [ 26.377935] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready [ 26.383409] bond0: Adding slave enp0s25 [ 26.627066] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready [ 26.627130] bond0: Enslaving enp0s25 as an active interface with a down link [ 26.632410] bond0: Adding slave enp7s0 [ 26.714000] IPv6: ADDRCONF(NETDEV_UP): enp7s0: link is not ready [ 26.714057] bond0: Enslaving enp7s0 as an active interface with a down link [ 27.211121] device bond0 entered promiscuous mode [ 27.218759] device xenbr0 entered promiscuous mode [ 27.221107] IPv6: ADDRCONF(NETDEV_UP): xenbr0: link is not ready [ 29.117955] e1000e: enp7s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 29.157892] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 29.157904] NFSD: starting 90-second grace period (net ffffffff818b2140) [ 29.176893] bond0: link status definitely up for interface enp7s0, 1000 Mbps full duplex [ 29.176897] bond0: making interface enp7s0 the new active one [ 29.176899] device enp7s0 entered promiscuous mode [ 29.177230] bond0: first active interface up! [ 29.177239] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready [ 29.177265] xenbr0: port 1(bond0) entered forwarding state [ 29.177271] xenbr0: port 1(bond0) entered forwarding state [ 29.177384] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready [ 29.522944] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 29.576944] bond0: link status definitely up for interface enp0s25, 1000 Mbps full duplex [ 31.946335] xen_acpi_processor: Uploading Xen processor PM info [ 34.446872] vif vif-1-0 pfsense.0: renamed from vif1.0 [ 34.531662] device pfsense.0 entered promiscuous mode [ 34.534200] IPv6: ADDRCONF(NETDEV_UP): pfsense.0: link is not ready [ 35.020524] xen_pciback: vpci: 0000:04:00.0: assign to virtual slot 0 [ 35.048250] pciback 0000:04:00.0: registering for 1 [ 35.052729] xen_pciback: vpci: 0000:0a:08.0: assign to virtual slot 1 [ 35.054293] pciback 0000:0a:08.0: registering for 1 [ 35.054987] xen_pciback: vpci: 0000:0a:0b.0: assign to virtual slot 2 [ 35.056013] pciback 0000:0a:0b.0: registering for 1 [ 36.378547] xenbr0: port 2(pfsense.0) entered disabled state [ 36.378820] device pfsense.0 left promiscuous mode [ 36.378824] xenbr0: port 2(pfsense.0) entered disabled state [ 44.217632] xenbr0: port 1(bond0) entered forwarding state [-- Attachment #3: xl.dmesg --] [-- Type: text/plain, Size: 35396 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@mydomain.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=n Mon Nov 16 00:28:43 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot hvm_debug=0xc3f dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.441382] Detected 2394.640 MHz processor. (XEN) [ 1.448760] Initing memory sharing. (XEN) [ 1.453220] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.460065] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.470189] Intel machine check reporting enabled (XEN) [ 1.475730] alt table ffff82d0802cfa90 -> ffff82d0802d0bd0 (XEN) [ 1.482169] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.490663] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.496730] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.503207] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.509443] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.515753] Intel VT-d Snoop Control not enabled. (XEN) [ 1.521288] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.527439] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.533215] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.538926] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.553273] I/O virtualisation enabled (XEN) [ 1.557851] - Dom0 mode: Relaxed (XEN) [ 1.562156] Interrupt remapping enabled (XEN) [ 1.566829] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.573274] ENABLING IO-APIC IRQs (XEN) [ 1.577503] -> Using old ACK method (XEN) [ 1.582231] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.791374] TSC deadline timer enabled (XEN) [ 2.136059] Platform timer is 14.318MHz HPET (XEN) [ 2.140937] 'A' pressed -> using alternative key handling (XEN) [ 2.141635] Allocated console ring of 64 KiB. (XEN) [ 2.142750] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.143804] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.144326] mwait-idle: v0.4 model 0x2a (XEN) [ 2.144846] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.145411] VMX: Supported advanced features: (XEN) [ 2.145930] - APIC MMIO access virtualisation (XEN) [ 2.146451] - APIC TPR shadow (XEN) [ 2.146995] - Extended Page Tables (EPT) (XEN) [ 2.147512] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.148037] - Virtual NMI (XEN) [ 2.148578] - MSR direct-access bitmap (XEN) [ 2.149094] - Unrestricted Guest (XEN) [ 2.149601] HVM: ASIDs enabled. (XEN) [ 2.150142] HVM: VMX enabled (XEN) [ 2.150643] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.151160] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.152313] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.153348] Brought up 8 CPUs (XEN) [ 2.154167] microcode: CPU6 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.160830] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.161348] microcode: CPU5 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.182523] ACPI sleep modes: S3 (XEN) [ 2.183029] mcheck_poll: Machine check polling timer started. (XEN) [ 2.183558] Dom0 has maximum 792 PIRQs (XEN) [ 2.184145] *** LOADING DOMAIN 0 *** (XEN) [ 2.366018] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 2.366569] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 2.367802] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 2.368310] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 2.369366] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 2.369890] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 2.370399] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 2.370919] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 2.371440] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 2.371960] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 2.372481] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 2.373003] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 2.373523] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 2.374081] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 2.375422] Dom0 has maximum 8 VCPUs (XEN) [ 5.541030] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 5.549328] Std. Loglevel: All (XEN) [ 5.549870] Guest Loglevel: All (XEN) [ 5.550375] Xen is relinquishing VGA console. (XEN) [ 5.551450] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) [ 5.551490] Freed 316kB init memory. (XEN) [ 5.551497] '0' pressed -> dumping Dom0's registers (XEN) [ 5.551500] *** Dumping Dom0 vcpu#0 state: *** (XEN) [ 5.551503] RIP: e033:[<ffffffff818e31f0>] (XEN) [ 5.551505] RFLAGS: 0000000000000200 EM: 1 CONTEXT: pv guest (d0v0) (XEN) [ 5.551508] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551510] rdx: 0000000000000000 rsi: ffffffff82400000 rdi: 0000000000000000 (XEN) [ 5.551512] rbp: 0000000000000000 rsp: ffffffff82419000 r8: 0000000000000000 (XEN) [ 5.551514] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551515] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551517] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551519] cr3: 0000000802401000 cr2: 0000000000000000 (XEN) [ 5.551521] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) [ 5.551523] Guest stack trace from rsp=ffffffff82419000: (XEN) [ 5.551524] Stack empty. (XEN) [ 5.551532] *** Dumping Dom0 vcpu#1 state: *** (XEN) [ 5.551536] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551538] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v1) (XEN) [ 5.551541] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551544] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551546] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551548] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551550] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551553] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551555] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551558] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551589] *** Dumping Dom0 vcpu#2 state: *** (XEN) [ 5.551592] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551594] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v2) (XEN) [ 5.551597] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551599] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551601] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551603] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551604] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551606] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551608] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551609] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551616] *** Dumping Dom0 vcpu#3 state: *** (XEN) [ 5.551618] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551620] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v3) (XEN) [ 5.551623] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551624] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551626] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551628] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551629] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551631] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551632] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551634] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551663] *** Dumping Dom0 vcpu#4 state: *** (XEN) [ 5.551666] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551667] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v4) (XEN) [ 5.551671] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551672] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551674] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551676] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551678] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551679] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551681] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551683] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551689] *** Dumping Dom0 vcpu#5 state: *** (XEN) [ 5.551691] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551693] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v5) (XEN) [ 5.551695] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551697] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551699] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551700] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551702] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551704] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551705] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551707] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551735] *** Dumping Dom0 vcpu#6 state: *** (XEN) [ 5.551739] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551741] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v6) (XEN) [ 5.551744] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551746] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551747] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551749] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551751] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551752] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551754] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551756] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.551762] *** Dumping Dom0 vcpu#7 state: *** (XEN) [ 5.551764] RIP: 0000:[<0000000000000000>] (XEN) [ 5.551765] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v7) (XEN) [ 5.551768] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 5.551770] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 5.551771] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 5.551773] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 5.551775] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 5.551777] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 5.551778] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 5.551780] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 5.807770] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.807775] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) [ 5.807779] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) [ 5.807782] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.807785] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) [ 5.807789] traps.c:2616:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.807792] traps.c:2616:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.893982] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.893989] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080cab3000 to 0xffffffff81646d10. (XEN) [ 5.893995] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080cab3080 to 0xffffffff81648e70. (XEN) [ 5.894000] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.894005] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000175 from 0xffff83080cab7fc0 to 0x0000000000000000. (XEN) [ 5.894010] traps.c:2616:d0v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.894015] traps.c:2616:d0v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.894314] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.894319] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000082 from 0xffff83080caa3000 to 0xffffffff81646d10. (XEN) [ 5.894323] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000083 from 0xffff83080caa3080 to 0xffffffff81648e70. (XEN) [ 5.894327] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.894330] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000175 from 0xffff83080caa7fc0 to 0x0000000000000000. (XEN) [ 5.894333] traps.c:2616:d0v2 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.894336] traps.c:2616:d0v2 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.894614] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.894618] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca93000 to 0xffffffff81646d10. (XEN) [ 5.894621] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca93080 to 0xffffffff81648e70. (XEN) [ 5.894624] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.894627] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca97fc0 to 0x0000000000000000. (XEN) [ 5.894631] traps.c:2616:d0v3 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.894634] traps.c:2616:d0v3 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.894876] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.894881] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca83000 to 0xffffffff81646d10. (XEN) [ 5.894885] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca83080 to 0xffffffff81648e70. (XEN) [ 5.894888] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.894891] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca87fc0 to 0x0000000000000000. (XEN) [ 5.894895] traps.c:2616:d0v4 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.894898] traps.c:2616:d0v4 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.895132] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.895136] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063f3000 to 0xffffffff81646d10. (XEN) [ 5.895139] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063f3080 to 0xffffffff81648e70. (XEN) [ 5.895143] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.895146] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000175 from 0xffff8308063f7fc0 to 0x0000000000000000. (XEN) [ 5.895149] traps.c:2616:d0v5 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.895152] traps.c:2616:d0v5 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.895366] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.895371] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063eb000 to 0xffffffff81646d10. (XEN) [ 5.895374] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063eb080 to 0xffffffff81648e70. (XEN) [ 5.895378] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.895381] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000175 from 0xffff8308063effc0 to 0x0000000000000000. (XEN) [ 5.895384] traps.c:2616:d0v6 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.895387] traps.c:2616:d0v6 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.895587] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.895591] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063db000 to 0xffffffff81646d10. (XEN) [ 5.895595] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063db080 to 0xffffffff81648e70. (XEN) [ 5.895598] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.895601] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000175 from 0xffff8308063dffc0 to 0x0000000000000000. (XEN) [ 5.895604] traps.c:2616:d0v7 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 5.895607] traps.c:2616:d0v7 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 7.037608] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 7.037611] PCI add device 0000:00:00.0 (XEN) [ 7.037815] PCI add device 0000:00:01.0 (XEN) [ 7.037998] PCI add device 0000:00:01.1 (XEN) [ 7.038256] PCI add device 0000:00:02.0 (XEN) [ 7.038443] PCI add device 0000:00:06.0 (XEN) [ 7.038728] PCI add device 0000:00:16.0 (XEN) [ 7.039010] PCI add device 0000:00:19.0 (XEN) [ 7.039304] PCI add device 0000:00:1a.0 (XEN) [ 7.039605] PCI add device 0000:00:1b.0 (XEN) [ 7.039862] PCI add device 0000:00:1c.0 (XEN) [ 7.040124] PCI add device 0000:00:1c.4 (XEN) [ 7.040379] PCI add device 0000:00:1c.6 (XEN) [ 7.040677] PCI add device 0000:00:1d.0 (XEN) [ 7.040888] PCI add device 0000:00:1e.0 (XEN) [ 7.041140] PCI add device 0000:00:1f.0 (XEN) [ 7.041414] PCI add device 0000:00:1f.2 (XEN) [ 7.041597] PCI add device 0000:00:1f.3 (XEN) [ 7.041870] PCI add device 0000:01:00.0 (XEN) [ 7.058091] PCI add device 0000:02:00.0 (XEN) [ 7.078114] PCI add device 0000:03:00.0 (XEN) [ 7.078561] PCI add device 0000:04:00.0 (XEN) [ 7.098298] PCI add device 0000:05:00.0 (XEN) [ 7.098723] PCI add device 0000:06:00.0 (XEN) [ 7.099456] PCI add device 0000:07:00.0 (XEN) [ 7.118414] PCI add device 0000:08:00.0 (XEN) [ 7.118748] PCI add device 0000:09:00.0 (XEN) [ 7.119220] PCI add device 0000:0a:08.0 (XEN) [ 7.119505] PCI add device 0000:0a:09.0 (XEN) [ 7.119790] PCI add device 0000:0a:0a.0 (XEN) [ 7.120106] PCI add device 0000:0a:0b.0 (XEN) [ 7.181681] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181701] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181744] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181762] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181806] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181824] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181831] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (XEN) [ 7.181849] traps.c:3188: GPF (0000): ffff82d08019920c -> ffff82d080239753 (d1) [ 35.051817] HVM Loader (d1) [ 35.052114] Detected Xen v4.5.2 (d1) [ 35.052502] Xenbus rings @0xfeffc000, event channel 1 (d1) [ 35.052958] System requested SeaBIOS (d1) [ 35.053163] CPU speed is 2395 MHz (d1) [ 35.054070] Relocating guest memory for lowmem MMIO space disabled (XEN) [ 35.054615] irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (d1) [ 35.054943] PCI-ISA link 0 routed to IRQ5 (XEN) [ 35.055101] irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (d1) [ 35.055444] PCI-ISA link 1 routed to IRQ10 (XEN) [ 35.055550] irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (d1) [ 35.055887] PCI-ISA link 2 routed to IRQ11 (XEN) [ 35.056081] irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (d1) [ 35.056482] PCI-ISA link 3 routed to IRQ5 (d1) [ 35.075043] pci dev 01:3 INTA->IRQ10 (d1) [ 35.079545] pci dev 02:0 INTA->IRQ11 (d1) [ 35.086386] pci dev 04:0 INTA->IRQ5 (d1) [ 35.090244] pci dev 05:0 INTA->IRQ10 (d1) [ 35.093997] pci dev 06:0 INTA->IRQ11 (d1) [ 35.118499] No RAM in high memory; setting high_mem resource base to 100000000 (d1) [ 35.119051] pci dev 03:0 bar 10 size 002000000: 0f0000008 (d1) [ 35.121185] pci dev 02:0 bar 14 size 001000000: 0f2000008 (d1) [ 35.122902] pci dev 04:0 bar 10 size 000020000: 0f3000004 (XEN) [ 35.123095] memory_map:add: dom1 gfn=f3000 mfn=f7c00 nr=20 (d1) [ 35.126537] pci dev 03:0 bar 30 size 000010000: 0f3020000 (d1) [ 35.127148] pci dev 04:0 bar 30 size 000010000: 0f3030000 (d1) [ 35.127823] pci dev 05:0 bar 30 size 000010000: 0f3040000 (d1) [ 35.128440] pci dev 06:0 bar 10 size 000010000: 0f3050000 (XEN) [ 35.128622] memory_map:add: dom1 gfn=f3050 mfn=f7800 nr=10 (d1) [ 35.133504] pci dev 03:0 bar 14 size 000001000: 0f3060000 (XEN) [ 35.133835] memory_map:add: dom1 gfn=f3061 mfn=f7842 nr=1 (d1) [ 35.137348] pci dev 05:0 bar 14 size 000001000: 0f3061000 (d1) [ 35.137981] pci dev 02:0 bar 10 size 000000100: 00000c001 (d1) [ 35.140362] pci dev 05:0 bar 10 size 000000100: 00000c101 (XEN) [ 35.140756] ioport_map:add: dom1 gport=c100 mport=c200 nr=100 (d1) [ 35.144081] pci dev 01:1 bar 20 size 000000010: 00000c201 (d1) [ 35.146209] Multiprocessor initialisation: (d1) [ 35.170094] - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 35.194130] - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 35.194228] Testing HVM environment: (d1) [ 35.199409] - REP INSB across page boundaries ... passed (d1) [ 35.201608] - GS base MSRs and SWAPGS ... passed (d1) [ 35.201628] Passed 2 of 2 tests (d1) [ 35.201654] Writing SMBIOS tables ... (d1) [ 35.202377] Loading SeaBIOS ... (d1) [ 35.202416] Creating MP tables ... (d1) [ 35.202506] Loading ACPI ... (d1) [ 35.203919] vm86 TSS at fc00a380 (d1) [ 35.204227] BIOS map: (d1) [ 35.204254] 10000-100d3: Scratch space (d1) [ 35.204280] e0000-fffff: Main BIOS (d1) [ 35.204293] E820 table: (d1) [ 35.204340] [00]: 00000000:00000000 - 00000000:000a0000: RAM (d1) [ 35.204383] HOLE: 00000000:000a0000 - 00000000:000e0000 (d1) [ 35.204435] [01]: 00000000:000e0000 - 00000000:00100000: RESERVED (d1) [ 35.204483] [02]: 00000000:00100000 - 00000000:27800000: RAM (d1) [ 35.204525] HOLE: 00000000:27800000 - 00000000:fc000000 (d1) [ 35.204577] [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d1) [ 35.204790] Invoking SeaBIOS ... (XEN) [ 36.063957] Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) [ 36.063959] ************* VMCS Area ************** (XEN) [ 36.063960] *** Guest State *** (XEN) [ 36.063961] CR0: actual=0x0000000000000039, shadow=0x0000000000000011, gh_mask=ffffffffffffffff (XEN) [ 36.063963] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) [ 36.063964] CR3: actual=0x0000000000800000, target_count=0 (XEN) [ 36.063966] target0=0000000000000000, target1=0000000000000000 (XEN) [ 36.063967] target2=0000000000000000, target3=0000000000000000 (XEN) [ 36.063968] RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = 0x0000000100000000 (0x0000000100000000) (XEN) [ 36.063970] RFLAGS=0x0000000000000006 (0x0000000000000006) DR7 = 0x0000000000000400 (XEN) [ 36.063971] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) [ 36.063973] CS: sel=0x0008, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063975] DS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063976] SS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063978] ES: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063979] FS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063980] GS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.063982] GDTR: limit=0x00000037, base=0x00000000000f6d80 (XEN) [ 36.063983] LDTR: sel=0x0000, attr=0x00082, limit=0x00000000, base=0x0000000000000000 (XEN) [ 36.063985] IDTR: limit=0x00000000, base=0x00000000000f6dbe (XEN) [ 36.063986] TR: sel=0x0000, attr=0x0008b, limit=0x000000ff, base=0x0000000000000000 (XEN) [ 36.063987] Guest PAT = 0x0007040600070406 (XEN) [ 36.063989] TSC Offset = ffffffe3da7c0a52 (XEN) [ 36.063990] DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) [ 36.063991] Interruptibility=0000 ActivityState=0000 (XEN) [ 36.063992] *** Host State *** (XEN) [ 36.063993] RSP = 0xffff83080ca97f90 RIP = 0xffff82d0801f4820 (XEN) [ 36.063994] CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) [ 36.063996] FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff83080ca9ec80 (XEN) [ 36.063997] GDTBase=ffff83080ca9a000 IDTBase=ffff83080ca9d000 (XEN) [ 36.063999] CR0=000000008005003b CR3=000000070bf71000 CR4=00000000000426f0 (XEN) [ 36.064000] Sysenter RSP=ffff83080ca97fc0 CS:RIP=e008:ffff82d080235550 (XEN) [ 36.064002] Host PAT = 0x0000050100070406 (XEN) [ 36.064003] *** Control State *** (XEN) [ 36.064004] PinBased=0000003f CPUBased=b6a065fe SecondaryExec=000000eb (XEN) [ 36.064005] EntryControls=000051ff ExitControls=000fefff (XEN) [ 36.064006] ExceptionBitmap=000600c2 (XEN) [ 36.064007] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.064008] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.064010] reason=80000021 qualification=00000000 (XEN) [ 36.064011] IDTVectoring: info=00000000 errcode=00000000 (XEN) [ 36.064012] TPR Threshold = 0x00 (XEN) [ 36.064013] EPT pointer = 0x000000070bf3f01e (XEN) [ 36.064014] Virtual processor ID = 0x0011 (XEN) [ 36.064015] ************************************** (XEN) [ 36.064016] domain_crash called from vmx.c:2505 (XEN) [ 36.064017] Domain 1 (vcpu#0) crashed on cpu#3: (XEN) [ 36.064019] ----[ Xen-4.5.2 x86_64 debug=n Not tainted ]---- (XEN) [ 36.064021] CPU: 3 (XEN) [ 36.064022] RIP: 0008:[<0000000100000000>] (XEN) [ 36.064023] RFLAGS: 0000000000000006 CONTEXT: hvm guest (d1v0) (XEN) [ 36.064025] rax: 0000000000000000 rbx: 0000000000000000 rcx: 00000000ffff1720 (XEN) [ 36.064027] rdx: 0000000000000059 rsi: 0000000000000059 rdi: 0000000000000000 (XEN) [ 36.064028] rbp: 0000000000000000 rsp: 0000000000006fdc r8: 0000000000000000 (XEN) [ 36.064029] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 36.064030] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 36.064032] r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) [ 36.064033] cr3: 0000000000800000 cr2: 0000000000000000 (XEN) [ 36.064034] ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 [-- Attachment #4: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 0:39 ` Atom2 @ 2015-11-16 10:02 ` Andrew Cooper 0 siblings, 0 replies; 43+ messages in thread From: Andrew Cooper @ 2015-11-16 10:02 UTC (permalink / raw) To: Atom2; +Cc: Jan Beulich, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2035 bytes --] On 16/11/15 00:39, Atom2 wrote: > Am 15.11.15 um 16:12 schrieb Andrew Cooper: > [big snip] >> Great - so confirms the issue as a SeaBIOS interaction issue, rather >> than a hypervisor regression. >> >> As I said before, I am still certain that a guest should not be able >> to get itself into the crashing state (short of a hardware errata), >> so I still suspect that there is a latent hypervisor emulation bug >> which has been tickled by the SeaBIOS update. >> >> Would you please mind running the bad HVMLoader on Xen 4.5.2 with >> hvm_debug=0xc3f ? I am still hoping that that will shed some light on >> SeaBIOS actions just leading up to the crash. > Hi Andrew, > Please see the attached two files. One is the dmesg from booting the > system. This looks pretty normal in my view. The other is the output > of "xl dmesg" which is most likely what you were after. It's probably > worth noting that the "traps.c" output between lines 259 and 314 and > again between lines 346 and 353 seem to be xen-4.5.2 specific and > don't show up under xen-4.5.1, but that may not be of any relevance > for the SeaBIOS issue we are experiencing. Though I'd still be > interested to know whether that's anything for me to worry about ... Sorry, but you need to be using a debug build of Xen. The internals of hvm_debug are not compiled in a regular build. I am also only interested in `xl dmesg`. There will be lots of log lines prefixed with [HVM:$DOMID.$VCPUID]. >> >> Are you able to experiment with newer versions of Xen? It would be >> interesting to see whether the issue is still present in Xen 4.6 > Currently xen-4.6 is not stable in gentoo and I try to stick to stable > packages as much as possible. But in case the above does not help you > any further, I am happy to give this a try as well. Would this just be > a straightforward test to see whether it works at all or would you > require debug symbols as well? That's ok. It is unlikely that this issue has been fixed since, so I suspect that it is still present. ~Andrew [-- Attachment #1.2: Type: text/html, Size: 3003 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-15 0:14 ` Atom2 2015-11-15 15:12 ` Andrew Cooper @ 2015-11-15 20:12 ` Doug Goldstein 2015-11-16 1:05 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Doug Goldstein @ 2015-11-15 20:12 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 7649 bytes --] On 11/14/15 6:14 PM, Atom2 wrote: > Am 14.11.15 um 21:32 schrieb Andrew Cooper: >> On 14/11/2015 00:16, Atom2 wrote: >>> Am 13.11.15 um 11:09 schrieb Andrew Cooper: >>>> On 13/11/15 07:25, Jan Beulich wrote: >>>>>>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >>>>>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>>>>> On 12/11/15 14:29, Atom2 wrote: >>>>>>>> Hi Andrew, >>>>>>>> thanks for your reply. Answers are inline further down. >>>>>>>> >>>>>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>>>>>> of the >>>>>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>>>>> >>>>>>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>>>>>> domU which is started as part of the machine booting up: >>>>>>>>>>> [...] >>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>>>>> state (0). >>>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>>>>> odd? That will be the source of the failure. >>>>>>>>> >>>>>>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>>>>>> should not be possible to set any of them. >>>>>>>>> >>>>>>>>> I suspect that the guest has exited for emulation, and there has been a >>>>>>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>>>>>> that there is a hardware errata which allows the guest to accidentally >>>>>>>>> get it self into this condition. >>>>>>>>> >>>>>>>>> Are you able to rerun with a debug build of the hypervisor? > [big snip] >>>>>>>> Now _without_ the debug USE flag, but with debug information in >>>>>>>> the binary (I used splitdebug), all is back to where the problem >>>>>>>> started off (i.e. the system boots without issues until such >>>>>>>> time it starts a HVM domU which then crashes; PV domUs are >>>>>>>> working). I have attached the latest "xl dmesg" output with the >>>>>>>> timing information included. >>>>>>>> >>> >>> I hope any of this makes sense to you. >>> >>> Again many thanks and best regards >>> >> >> Right - it would appear that the USE flag is definitely not what you >> wanted, and causes bad compilation for Xen. The do_IRQ disassembly >> you sent is a the result of disassembling a whole block of zeroes. >> Sorry for leading you on a goose chase - the double faults will be the >> product of bad compilation, rather than anything to do with your >> specific problem. > Hi Andrew, > there's absolutely no need to appologize as it is me who asked for help > and you who generously stepped in and provided it. I really do > appreciate your help and it is for me, as the one seeking help, to > provide all the information you deem necessary and you ask for. >> However, the final log you sent (dmesg) is using a debug Xen, which is >> what I was attempting to get you to do originally. > Next time I know better how to arrive at a debug XEN. It's all about > learning. >> We still observe that the VM ends up in 32bit non-paged mode but with >> an RIP with bit 32 set, which is an invalid state to be in. However, >> there was nothing particularly interesting in the extra log information. >> >> Please can you rerun with "hvm_debug=0xc3f", which will cause far more >> logging to occur to the console while the HVM guest is running. That >> might show some hints. > I haven't done that yet - but please see my next paragraph. If you are > still interested in this, for whatever reason, I am clearly more than > happy to rerun with your suggested option and provide that information > as well. >> Also, the fact that this occurs just after starting SeaBIOS is >> interesting. As you have switched versions of Xen, you have also >> switched hvmloader, which contains the SeaBIOS binary embedded in it. >> Would you be able to compile both 4.5.1 and 4.5.2 and switch the >> hvmloader binaries in use. It would be very interesting to see >> whether the failure is caused by the hvmloader binary or the >> hypervisor. (With `xl`, you can use >> firmware_override="/full/path/to/firmware" to override the default >> hvmloader). > Your analysis was absolutely spot on. After re-thinking this for a > moment, I thought going down that route first would make a lot of sense > as PV guests still do work and one of the differences to HVM domUs is > that the former do _not_ require SeaBIOS. Looking at my log files of > installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in > the relevant timeframe which obviously had not made it to the hvmloader > of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. > > So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS > 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed > to strongly indicate that there indeed might be an issue with SeaBIOS as > this probably was the only variable that had changed from the original > install of xen-4.5.1. > > My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile > xen-4.5.1. Voila, the system was again up and running. While still > having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you > probably guessed it ... the problem was gone: The system boots up with > no issues and everything is fine again. > > So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 > preventing HVM doamins from successfully starting up. I don't know what > this is triggered from, if this is specific to my hardware or whether > something else in my environment is to blame. > > In any case, I am again more than happy to provide data / run a few > tests should you wish to get to the grounds of this. > > I do owe you a beer (or any other drink) should you ever be at my > location (i.e. Vienna, Austria). > > Many thanks again for your analysis and your first class support. Xen > and their people absolutely rock! > > Atom2 I'm a little late to the thread but can you send me (you can do it off-list if you'd like) the USE flags you used for xen, xen-tools and seabios? Also emerge --info. You can kill two birds with one stone by using emerge --info xen. I'm not too familiar with the xen ebuilds but I was pretty sure that xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS and builds it so that it remains consistent. But obviously your experience shows otherwise. I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and your info would be helpful. -- Doug Goldstein [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-15 20:12 ` Doug Goldstein @ 2015-11-16 1:05 ` Atom2 2015-11-16 15:31 ` Konrad Rzeszutek Wilk 2015-11-16 19:47 ` Doug Goldstein 0 siblings, 2 replies; 43+ messages in thread From: Atom2 @ 2015-11-16 1:05 UTC (permalink / raw) To: Doug Goldstein, xen-devel [-- Attachment #1: Type: text/plain, Size: 9115 bytes --] Am 15.11.15 um 21:12 schrieb Doug Goldstein: > On 11/14/15 6:14 PM, Atom2 wrote: >> Am 14.11.15 um 21:32 schrieb Andrew Cooper: >>> On 14/11/2015 00:16, Atom2 wrote: >>>> Am 13.11.15 um 11:09 schrieb Andrew Cooper: >>>>> On 13/11/15 07:25, Jan Beulich wrote: >>>>>>>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >>>>>>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>>>>>> On 12/11/15 14:29, Atom2 wrote: >>>>>>>>> Hi Andrew, >>>>>>>>> thanks for your reply. Answers are inline further down. >>>>>>>>> >>>>>>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>>>>>>> After the upgrade HVM domUs appear to no longer work - regardless >>>>>>>>>>>> of the >>>>>>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >>>>>>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>>>>>> >>>>>>>>>>>> xl dmesg shows the following information after the first crashed HVM >>>>>>>>>>>> domU which is started as part of the machine booting up: >>>>>>>>>>>> [...] >>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >>>>>>>>>>>> state (0). >>>>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>>>> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>>>>>> Other than RIP looking odd for a guest still in non-paged protected >>>>>>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>>>>>> odd? That will be the source of the failure. >>>>>>>>>> >>>>>>>>>> Out of long mode, the upper 32bit of %rip should all be zero, and it >>>>>>>>>> should not be possible to set any of them. >>>>>>>>>> >>>>>>>>>> I suspect that the guest has exited for emulation, and there has been a >>>>>>>>>> bad update to %rip. The alternative (which I hope is not the case) is >>>>>>>>>> that there is a hardware errata which allows the guest to accidentally >>>>>>>>>> get it self into this condition. >>>>>>>>>> >>>>>>>>>> Are you able to rerun with a debug build of the hypervisor? >> [big snip] >>>>>>>>> Now _without_ the debug USE flag, but with debug information in >>>>>>>>> the binary (I used splitdebug), all is back to where the problem >>>>>>>>> started off (i.e. the system boots without issues until such >>>>>>>>> time it starts a HVM domU which then crashes; PV domUs are >>>>>>>>> working). I have attached the latest "xl dmesg" output with the >>>>>>>>> timing information included. >>>>>>>>> >>>> I hope any of this makes sense to you. >>>> >>>> Again many thanks and best regards >>>> >>> Right - it would appear that the USE flag is definitely not what you >>> wanted, and causes bad compilation for Xen. The do_IRQ disassembly >>> you sent is a the result of disassembling a whole block of zeroes. >>> Sorry for leading you on a goose chase - the double faults will be the >>> product of bad compilation, rather than anything to do with your >>> specific problem. >> Hi Andrew, >> there's absolutely no need to appologize as it is me who asked for help >> and you who generously stepped in and provided it. I really do >> appreciate your help and it is for me, as the one seeking help, to >> provide all the information you deem necessary and you ask for. >>> However, the final log you sent (dmesg) is using a debug Xen, which is >>> what I was attempting to get you to do originally. >> Next time I know better how to arrive at a debug XEN. It's all about >> learning. >>> We still observe that the VM ends up in 32bit non-paged mode but with >>> an RIP with bit 32 set, which is an invalid state to be in. However, >>> there was nothing particularly interesting in the extra log information. >>> >>> Please can you rerun with "hvm_debug=0xc3f", which will cause far more >>> logging to occur to the console while the HVM guest is running. That >>> might show some hints. >> I haven't done that yet - but please see my next paragraph. If you are >> still interested in this, for whatever reason, I am clearly more than >> happy to rerun with your suggested option and provide that information >> as well. >>> Also, the fact that this occurs just after starting SeaBIOS is >>> interesting. As you have switched versions of Xen, you have also >>> switched hvmloader, which contains the SeaBIOS binary embedded in it. >>> Would you be able to compile both 4.5.1 and 4.5.2 and switch the >>> hvmloader binaries in use. It would be very interesting to see >>> whether the failure is caused by the hvmloader binary or the >>> hypervisor. (With `xl`, you can use >>> firmware_override="/full/path/to/firmware" to override the default >>> hvmloader). >> Your analysis was absolutely spot on. After re-thinking this for a >> moment, I thought going down that route first would make a lot of sense >> as PV guests still do work and one of the differences to HVM domUs is >> that the former do _not_ require SeaBIOS. Looking at my log files of >> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in >> the relevant timeframe which obviously had not made it to the hvmloader >> of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. >> >> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >> 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed >> to strongly indicate that there indeed might be an issue with SeaBIOS as >> this probably was the only variable that had changed from the original >> install of xen-4.5.1. >> >> My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile >> xen-4.5.1. Voila, the system was again up and running. While still >> having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you >> probably guessed it ... the problem was gone: The system boots up with >> no issues and everything is fine again. >> >> So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 >> preventing HVM doamins from successfully starting up. I don't know what >> this is triggered from, if this is specific to my hardware or whether >> something else in my environment is to blame. >> >> In any case, I am again more than happy to provide data / run a few >> tests should you wish to get to the grounds of this. >> >> I do owe you a beer (or any other drink) should you ever be at my >> location (i.e. Vienna, Austria). >> >> Many thanks again for your analysis and your first class support. Xen >> and their people absolutely rock! >> >> Atom2 > I'm a little late to the thread but can you send me (you can do it > off-list if you'd like) the USE flags you used for xen, xen-tools and > seabios? Also emerge --info. You can kill two birds with one stone by > using emerge --info xen. Hi Doug, here you go: USE flags: app-emulation/xen-4.5.2-r1::gentoo USE="-custom-cflags -debug -efi -flask -xsm" app-emulation/xen-tools-4.5.2::gentoo USE="hvm pam pygrub python qemu screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) -ovmf -static-libs -system-qemu" PYTHON_TARGETS="python2_7" sys-firmware/seabios-1.7.5::gentoo USE="binary" emerge --info: Please see the attached file > I'm not too familiar with the xen ebuilds but I was pretty sure that > xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS > and builds it so that it remains consistent. But obviously your > experience shows otherwise. You are right, it's xen-tools that builds hvmloader. If I remember correctly, the "system-seabios" USE flag (for xen-tools) specifies whether sys-firmware/seabios is used and the latter downloads SeaBIOS in it's binary form provided its "binary" USE flag is set. At least that's my understanding. > I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and > your info would be helpful. Great. Whatever makes gentoo and xen stronger will be awesome. What immediately springs to mind is to create a separate hvmloader package and slot that (that's just an idea and probably not fully thought through, but ss far as I understood Andrew, it would then be possible to specify the specific firmware version [i.e. hvmloader] to use on xl's command line by using firmware_override="full/path/to/firmware"). I also found out that an upgrade to sys-firmware/seabios obviously does not trigger an automatic re-emerge of xen-tools and thus hvmloader. Shouldn't this also happen automatically as xen-tools depends on seabios? Thanks and best regards Atom2 P.S. If you prefer to take this off-list, just reply to my mail address. [-- Attachment #2: info --] [-- Type: text/plain, Size: 3773 bytes --] Portage 2.2.20.1 (python 2.7.10-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.21-r1, 4.1.7-hardened-r1 x86_64) ================================================================= System uname: Linux-4.1.7-hardened-r1-x86_64-Intel-R-_Xeon-R-_CPU_E31260L_@_2.40GHz-with-gentoo-2.2 KiB Mem: 4032716 total, 3678784 free KiB Swap: 16777148 total, 16777148 free Timestamp of repository gentoo: Sun, 15 Nov 2015 00:45:01 +0000 sh bash 4.3_p39 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p39::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10::gentoo, 3.4.3::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.17::gentoo sys-apps/sandbox: 2.6-r1::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.8.5::gentoo, 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) sys-libs/glibc: 2.21-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.europe.gentoo.org/gentoo-portage/ priority: -1000 x-portage location: /usr/local/portage masters: gentoo priority: 0 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build=y --buildpkg-exclude sys-kernel/hardened-sources" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://gd.tuwien.ac.at/opsys/linux/gentoo/" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--quiet --progress" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" USE="acl aes amd64 avx bash-completion berkdb bzip2 cli cracklib crypt cxx gdbm hardened iconv justify lm_sensors mmx mmxext modules multilib ncurses nls nptl openmp pam pax_kernel pcre pie popcnt readline seccomp session sse sse2 sse3 sse4.1 sse4_1 ssl ssp ssse3 tcpd unicode urandom vim-syntax xattr xtpax zlib" ABI_X86="64" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4.1 ssse3" ELIBC="glibc" KERNEL="linux" LINGUAS="en" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby20" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 1:05 ` Atom2 @ 2015-11-16 15:31 ` Konrad Rzeszutek Wilk 2015-11-16 19:16 ` Atom2 2015-11-16 19:47 ` Doug Goldstein 1 sibling, 1 reply; 43+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-11-16 15:31 UTC (permalink / raw) To: Atom2; +Cc: Doug Goldstein, xen-devel > >>Your analysis was absolutely spot on. After re-thinking this for a > >>moment, I thought going down that route first would make a lot of sense > >>as PV guests still do work and one of the differences to HVM domUs is > >>that the former do _not_ require SeaBIOS. Looking at my log files of > >>installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in > >>the relevant timeframe which obviously had not made it to the hvmloader > >>of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. > >> > >>So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS > >>1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed > >>to strongly indicate that there indeed might be an issue with SeaBIOS as > >>this probably was the only variable that had changed from the original > >>install of xen-4.5.1. I recall seeing this way back in Fedora 20 days. I narrowed it down the SeaBIOS version that was a standalone package to not have CONFIG_XEN. Having that fixed in the SeaBIOS package fixed it. > >> > >>My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile > >>xen-4.5.1. Voila, the system was again up and running. While still > >>having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you > >>probably guessed it ... the problem was gone: The system boots up with > >>no issues and everything is fine again. > >> > >>So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 > >>preventing HVM doamins from successfully starting up. I don't know what > >>this is triggered from, if this is specific to my hardware or whether > >>something else in my environment is to blame. > >> > >>In any case, I am again more than happy to provide data / run a few > >>tests should you wish to get to the grounds of this. > >> > >>I do owe you a beer (or any other drink) should you ever be at my > >>location (i.e. Vienna, Austria). > >> > >>Many thanks again for your analysis and your first class support. Xen > >>and their people absolutely rock! > >> > >>Atom2 > >I'm a little late to the thread but can you send me (you can do it > >off-list if you'd like) the USE flags you used for xen, xen-tools and > >seabios? Also emerge --info. You can kill two birds with one stone by > >using emerge --info xen. > Hi Doug, > here you go: > USE flags: > app-emulation/xen-4.5.2-r1::gentoo USE="-custom-cflags -debug -efi -flask > -xsm" > app-emulation/xen-tools-4.5.2::gentoo USE="hvm pam pygrub python qemu > screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) -ovmf > -static-libs -system-qemu" PYTHON_TARGETS="python2_7" > sys-firmware/seabios-1.7.5::gentoo USE="binary" > emerge --info: Please see the attached file > >I'm not too familiar with the xen ebuilds but I was pretty sure that > >xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS > >and builds it so that it remains consistent. But obviously your > >experience shows otherwise. > You are right, it's xen-tools that builds hvmloader. If I remember > correctly, the "system-seabios" USE flag (for xen-tools) specifies whether > sys-firmware/seabios is used and the latter downloads SeaBIOS in it's binary > form provided its "binary" USE flag is set. At least that's my > understanding. > >I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and > >your info would be helpful. > Great. Whatever makes gentoo and xen stronger will be awesome. What > immediately springs to mind is to create a separate hvmloader package and > slot that (that's just an idea and probably not fully thought through, but > ss far as I understood Andrew, it would then be possible to specify the > specific firmware version [i.e. hvmloader] to use on xl's command line by > using firmware_override="full/path/to/firmware"). > > I also found out that an upgrade to sys-firmware/seabios obviously does not > trigger an automatic re-emerge of xen-tools and thus hvmloader. Shouldn't > this also happen automatically as xen-tools depends on seabios? No and yes. You can use 'seabios' also with a standalone QEMU (so not hardware virtualization). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 15:31 ` Konrad Rzeszutek Wilk @ 2015-11-16 19:16 ` Atom2 2015-11-16 19:25 ` Konrad Rzeszutek Wilk 2015-11-16 23:01 ` Andrew Cooper 0 siblings, 2 replies; 43+ messages in thread From: Atom2 @ 2015-11-16 19:16 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Doug Goldstein, xen-devel Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>> Your analysis was absolutely spot on. After re-thinking this for a >>>> moment, I thought going down that route first would make a lot of sense >>>> as PV guests still do work and one of the differences to HVM domUs is >>>> that the former do _not_ require SeaBIOS. Looking at my log files of >>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in >>>> the relevant timeframe which obviously had not made it to the hvmloader >>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. >>>> >>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed >>>> to strongly indicate that there indeed might be an issue with SeaBIOS as >>>> this probably was the only variable that had changed from the original >>>> install of xen-4.5.1. > I recall seeing this way back in Fedora 20 days. I narrowed it down the > SeaBIOS version that was a standalone package to not have CONFIG_XEN. > > Having that fixed in the SeaBIOS package fixed it. Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! Konrad, you might have found an interesting point. I did have a look at the ebuild for the failing version and in there I found the following comment: ====== comment from ebuild ======= # Upstream hasn't released a new binary. We snipe ours from Fedora for now. # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz ====== end comment from ebuild ======= which might in fact underline that there might be an issue similar to what you described above. What is also pretty interesting is the fact that the old (working) SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS 1.8.2 installed in the same location is only half as big: 131.072 bytes. I checked at the download site and the 1.8.2 binary version is indeed not available from http://code.coreboot.org/p/seabios/downloads/. But both the binary versions for 1.7.5 and 1.8.0 are available and both are acutually 262.144 bytes in size, so I'd be very surprised if the 1.8.2 version is really only half that size. By the way, the old working version (according to the ebuild) was directly downloaded from the above url and also shows an identical SHA1 digest to that version available for download there. To me this looks as if something is really wrong here. If anybody of you has access to a 1.8.2 version, could you please confirm whether there's really that big a size difference between the 1.7.5 and the 1.8.2 versions? Or is that difference probably attributable to the missing CONFIG_XEN option? Andrew: I havent't gotten around to run the debug version of the hypervisor again, but if the current suspicion turns out to be true, there's probably not much value in that anyways. Would you agree? Thanks Atom2 >>>> My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile >>>> xen-4.5.1. Voila, the system was again up and running. While still >>>> having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you >>>> probably guessed it ... the problem was gone: The system boots up with >>>> no issues and everything is fine again. >>>> >>>> So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 >>>> preventing HVM doamins from successfully starting up. I don't know what >>>> this is triggered from, if this is specific to my hardware or whether >>>> something else in my environment is to blame. >>>> >>>> In any case, I am again more than happy to provide data / run a few >>>> tests should you wish to get to the grounds of this. >>>> >>>> I do owe you a beer (or any other drink) should you ever be at my >>>> location (i.e. Vienna, Austria). >>>> >>>> Many thanks again for your analysis and your first class support. Xen >>>> and their people absolutely rock! >>>> >>>> Atom2 >>> I'm a little late to the thread but can you send me (you can do it >>> off-list if you'd like) the USE flags you used for xen, xen-tools and >>> seabios? Also emerge --info. You can kill two birds with one stone by >>> using emerge --info xen. >> Hi Doug, >> here you go: >> USE flags: >> app-emulation/xen-4.5.2-r1::gentoo USE="-custom-cflags -debug -efi -flask >> -xsm" >> app-emulation/xen-tools-4.5.2::gentoo USE="hvm pam pygrub python qemu >> screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) -ovmf >> -static-libs -system-qemu" PYTHON_TARGETS="python2_7" >> sys-firmware/seabios-1.7.5::gentoo USE="binary" >> emerge --info: Please see the attached file >>> I'm not too familiar with the xen ebuilds but I was pretty sure that >>> xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS >>> and builds it so that it remains consistent. But obviously your >>> experience shows otherwise. >> You are right, it's xen-tools that builds hvmloader. If I remember >> correctly, the "system-seabios" USE flag (for xen-tools) specifies whether >> sys-firmware/seabios is used and the latter downloads SeaBIOS in it's binary >> form provided its "binary" USE flag is set. At least that's my >> understanding. >>> I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and >>> your info would be helpful. >> Great. Whatever makes gentoo and xen stronger will be awesome. What >> immediately springs to mind is to create a separate hvmloader package and >> slot that (that's just an idea and probably not fully thought through, but >> ss far as I understood Andrew, it would then be possible to specify the >> specific firmware version [i.e. hvmloader] to use on xl's command line by >> using firmware_override="full/path/to/firmware"). >> >> I also found out that an upgrade to sys-firmware/seabios obviously does not >> trigger an automatic re-emerge of xen-tools and thus hvmloader. Shouldn't >> this also happen automatically as xen-tools depends on seabios? > No and yes. You can use 'seabios' also with a standalone QEMU (so not > hardware virtualization). > en.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:16 ` Atom2 @ 2015-11-16 19:25 ` Konrad Rzeszutek Wilk 2015-11-16 19:39 ` Doug Goldstein 2015-11-16 19:45 ` Atom2 2015-11-16 23:01 ` Andrew Cooper 1 sibling, 2 replies; 43+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-11-16 19:25 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, Doug Goldstein, xen-devel On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote: > > > Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: > >>>>Your analysis was absolutely spot on. After re-thinking this for a > >>>>moment, I thought going down that route first would make a lot of sense > >>>>as PV guests still do work and one of the differences to HVM domUs is > >>>>that the former do _not_ require SeaBIOS. Looking at my log files of > >>>>installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in > >>>>the relevant timeframe which obviously had not made it to the hvmloader > >>>>of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. > >>>> > >>>>So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS > >>>>1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed > >>>>to strongly indicate that there indeed might be an issue with SeaBIOS as > >>>>this probably was the only variable that had changed from the original > >>>>install of xen-4.5.1. > >I recall seeing this way back in Fedora 20 days. I narrowed it down the > >SeaBIOS version that was a standalone package to not have CONFIG_XEN. > > > >Having that fixed in the SeaBIOS package fixed it. > Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! > Konrad, you might have found an interesting point. I did have a look at the > ebuild for the failing version and in there I found the following comment: > ====== comment from ebuild ======= > # Upstream hasn't released a new binary. We snipe ours from Fedora for > now. > # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz > ====== end comment from ebuild ======= > which might in fact underline that there might be an issue similar to what > you described above. > > What is also pretty interesting is the fact that the old (working) SeaBIOS > version 1.7.5 installed as "bios.bin" under /usr/share/seabios is actually > 262.144 bytes in size whereas the new (invalid) SeaBIOS 1.8.2 installed in > the same location is only half as big: 131.072 bytes. > > I checked at the download site and the 1.8.2 binary version is indeed not > available from http://code.coreboot.org/p/seabios/downloads/. But both the > binary versions for 1.7.5 and 1.8.0 are available and both are acutually > 262.144 bytes in size, so I'd be very surprised if the 1.8.2 version is > really only half that size. By the way, the old working version (according > to the ebuild) was directly downloaded from the above url and also shows an > identical SHA1 digest to that version available for download there. <blinks>I thought Gentoo was all about rebuilding from source and not taking binary blobs. > > To me this looks as if something is really wrong here. If anybody of you has > access to a 1.8.2 version, could you please confirm whether there's really > that big a size difference between the 1.7.5 and the 1.8.2 versions? Or is > that difference probably attributable to the missing CONFIG_XEN option? It may be other options too - like CONFIG_XHCI, or a huge amount of other ones. > > Andrew: I havent't gotten around to run the debug version of the hypervisor > again, but if the current suspicion turns out to be true, there's probably > not much value in that anyways. Would you agree? I am not Andrew and can't really speak for him, but I am going to take a leap here and say he will agree with you. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:25 ` Konrad Rzeszutek Wilk @ 2015-11-16 19:39 ` Doug Goldstein 2015-11-16 19:47 ` Konrad Rzeszutek Wilk 2015-11-16 19:45 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Doug Goldstein @ 2015-11-16 19:39 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, Atom2; +Cc: Andrew Cooper, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 4534 bytes --] On 11/16/15 1:25 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote: >> >> >> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>>> moment, I thought going down that route first would make a lot of sense >>>>>> as PV guests still do work and one of the differences to HVM domUs is >>>>>> that the former do _not_ require SeaBIOS. Looking at my log files of >>>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in >>>>>> the relevant timeframe which obviously had not made it to the hvmloader >>>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. >>>>>> >>>>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed >>>>>> to strongly indicate that there indeed might be an issue with SeaBIOS as >>>>>> this probably was the only variable that had changed from the original >>>>>> install of xen-4.5.1. >>> I recall seeing this way back in Fedora 20 days. I narrowed it down the >>> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >>> >>> Having that fixed in the SeaBIOS package fixed it. >> Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! >> Konrad, you might have found an interesting point. I did have a look at the >> ebuild for the failing version and in there I found the following comment: >> ====== comment from ebuild ======= >> # Upstream hasn't released a new binary. We snipe ours from Fedora for >> now. >> # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz >> ====== end comment from ebuild ======= >> which might in fact underline that there might be an issue similar to what >> you described above. >> >> What is also pretty interesting is the fact that the old (working) SeaBIOS >> version 1.7.5 installed as "bios.bin" under /usr/share/seabios is actually >> 262.144 bytes in size whereas the new (invalid) SeaBIOS 1.8.2 installed in >> the same location is only half as big: 131.072 bytes. >> >> I checked at the download site and the 1.8.2 binary version is indeed not >> available from http://code.coreboot.org/p/seabios/downloads/. But both the >> binary versions for 1.7.5 and 1.8.0 are available and both are acutually >> 262.144 bytes in size, so I'd be very surprised if the 1.8.2 version is >> really only half that size. By the way, the old working version (according >> to the ebuild) was directly downloaded from the above url and also shows an >> identical SHA1 digest to that version available for download there. > > <blinks>I thought Gentoo was all about rebuilding from source and not > taking binary blobs. So since SeaBIOS and friends (the blobs) are so sensitive to compilers and environments and to avoid as much problems for people as possible. I setup the ebuilds in Gentoo to grab the binary blobs by default and if the user disabled the binary option it would build from source. The idea was that Fedora doesn't ship any blobs that can't be rebuilt so I would follow so the same approach and even use their built blobs. But it appears to be that there are definitely differences between what QEMU needs/uses and what upstream ships. Its pretty common for saying Gentoo is about building from source but really its about user choice. That said I haven't been maintaining these for some time now and I've looked at the state of the way that SeaBIOS and friends are built and I believe there's an issue and I intend on remedying things soon to avoid issues like this. >> >> To me this looks as if something is really wrong here. If anybody of you has >> access to a 1.8.2 version, could you please confirm whether there's really >> that big a size difference between the 1.7.5 and the 1.8.2 versions? Or is >> that difference probably attributable to the missing CONFIG_XEN option? > > It may be other options too - like CONFIG_XHCI, or a huge amount of other > ones. Yes. There's definitely differences. >> >> Andrew: I havent't gotten around to run the debug version of the hypervisor >> again, but if the current suspicion turns out to be true, there's probably >> not much value in that anyways. Would you agree? > > I am not Andrew and can't really speak for him, but I am going to take a > leap here and say he will agree with you. > -- Doug Goldstein [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:39 ` Doug Goldstein @ 2015-11-16 19:47 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 43+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-11-16 19:47 UTC (permalink / raw) To: Doug Goldstein; +Cc: Andrew Cooper, Atom2, xen-devel On Mon, Nov 16, 2015 at 01:39:08PM -0600, Doug Goldstein wrote: > On 11/16/15 1:25 PM, Konrad Rzeszutek Wilk wrote: > > On Mon, Nov 16, 2015 at 08:16:33PM +0100, Atom2 wrote: > >> > >> > >> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: > >>>>>> Your analysis was absolutely spot on. After re-thinking this for a > >>>>>> moment, I thought going down that route first would make a lot of sense > >>>>>> as PV guests still do work and one of the differences to HVM domUs is > >>>>>> that the former do _not_ require SeaBIOS. Looking at my log files of > >>>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in > >>>>>> the relevant timeframe which obviously had not made it to the hvmloader > >>>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. > >>>>>> > >>>>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS > >>>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed > >>>>>> to strongly indicate that there indeed might be an issue with SeaBIOS as > >>>>>> this probably was the only variable that had changed from the original > >>>>>> install of xen-4.5.1. > >>> I recall seeing this way back in Fedora 20 days. I narrowed it down the > >>> SeaBIOS version that was a standalone package to not have CONFIG_XEN. > >>> > >>> Having that fixed in the SeaBIOS package fixed it. > >> Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! > >> Konrad, you might have found an interesting point. I did have a look at the > >> ebuild for the failing version and in there I found the following comment: > >> ====== comment from ebuild ======= > >> # Upstream hasn't released a new binary. We snipe ours from Fedora for > >> now. > >> # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz > >> ====== end comment from ebuild ======= > >> which might in fact underline that there might be an issue similar to what > >> you described above. > >> > >> What is also pretty interesting is the fact that the old (working) SeaBIOS > >> version 1.7.5 installed as "bios.bin" under /usr/share/seabios is actually > >> 262.144 bytes in size whereas the new (invalid) SeaBIOS 1.8.2 installed in > >> the same location is only half as big: 131.072 bytes. > >> > >> I checked at the download site and the 1.8.2 binary version is indeed not > >> available from http://code.coreboot.org/p/seabios/downloads/. But both the > >> binary versions for 1.7.5 and 1.8.0 are available and both are acutually > >> 262.144 bytes in size, so I'd be very surprised if the 1.8.2 version is > >> really only half that size. By the way, the old working version (according > >> to the ebuild) was directly downloaded from the above url and also shows an > >> identical SHA1 digest to that version available for download there. > > > > <blinks>I thought Gentoo was all about rebuilding from source and not > > taking binary blobs. > > So since SeaBIOS and friends (the blobs) are so sensitive to compilers > and environments and to avoid as much problems for people as possible. I > setup the ebuilds in Gentoo to grab the binary blobs by default and if > the user disabled the binary option it would build from source. The idea > was that Fedora doesn't ship any blobs that can't be rebuilt so I would > follow so the same approach and even use their built blobs. But it > appears to be that there are definitely differences between what QEMU > needs/uses and what upstream ships. > > Its pretty common for saying Gentoo is about building from source but > really its about user choice. Aaah! Thank you for educating me! > > That said I haven't been maintaining these for some time now and I've > looked at the state of the way that SeaBIOS and friends are built and I > believe there's an issue and I intend on remedying things soon to avoid > issues like this. Woot! > > >> > >> To me this looks as if something is really wrong here. If anybody of you has > >> access to a 1.8.2 version, could you please confirm whether there's really > >> that big a size difference between the 1.7.5 and the 1.8.2 versions? Or is > >> that difference probably attributable to the missing CONFIG_XEN option? > > > > It may be other options too - like CONFIG_XHCI, or a huge amount of other > > ones. > > Yes. There's definitely differences. > > >> > >> Andrew: I havent't gotten around to run the debug version of the hypervisor > >> again, but if the current suspicion turns out to be true, there's probably > >> not much value in that anyways. Would you agree? > > > > I am not Andrew and can't really speak for him, but I am going to take a > > leap here and say he will agree with you. > > > > > -- > Doug Goldstein > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:25 ` Konrad Rzeszutek Wilk 2015-11-16 19:39 ` Doug Goldstein @ 2015-11-16 19:45 ` Atom2 1 sibling, 0 replies; 43+ messages in thread From: Atom2 @ 2015-11-16 19:45 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Andrew Cooper, Doug Goldstein, xen-devel Am 16.11.15 um 20:25 schrieb Konrad Rzeszutek Wilk: [snip] > <blinks>I thought Gentoo was all about rebuilding from source and not > taking binary blobs. Well, you probably caught Gentoo on the wrong foot here, but generally it is what you thought it was. And IMHO that's the beauty of it. Applying a patch is therefore very easy, you just store the patch file in the appropriate directory and it will automatically be picked up by the build process. You could also decide to build SeaBIOS from source (it's just a change of a USE flag), but there's a reason why this is not the default and that warning pops up if you have decided to build from source: ==== warning from ebuild ===== You have decided to compile your own SeaBIOS. This is not supported by upstream unless you use their recommended toolchain (which you are not). If you are intending to use this build with QEMU, realize you will not receive any support if you have compiled your own SeaBIOS. Virtual machines subtly fail based on changes in SeaBIOS. ==== end warning from ebuild ===== In any case thanks for your support, your humour (:-) and I am glad you at least were not shocked by this information, Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:16 ` Atom2 2015-11-16 19:25 ` Konrad Rzeszutek Wilk @ 2015-11-16 23:01 ` Andrew Cooper 2015-11-16 23:10 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-16 23:01 UTC (permalink / raw) To: Atom2, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel On 16/11/2015 19:16, Atom2 wrote: > > > Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>> moment, I thought going down that route first would make a lot of >>>>> sense >>>>> as PV guests still do work and one of the differences to HVM domUs is >>>>> that the former do _not_ require SeaBIOS. Looking at my log files of >>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to >>>>> 1.8.2 in >>>>> the relevant timeframe which obviously had not made it to the >>>>> hvmloader >>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of >>>>> SeaBIOS. >>>>> >>>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that >>>>> seemed >>>>> to strongly indicate that there indeed might be an issue with >>>>> SeaBIOS as >>>>> this probably was the only variable that had changed from the >>>>> original >>>>> install of xen-4.5.1. >> I recall seeing this way back in Fedora 20 days. I narrowed it down the >> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >> >> Having that fixed in the SeaBIOS package fixed it. > Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! > Konrad, you might have found an interesting point. I did have a look > at the ebuild for the failing version and in there I found the > following comment: > ====== comment from ebuild ======= > # Upstream hasn't released a new binary. We snipe ours from > Fedora for now. > # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz > ====== end comment from ebuild ======= > which might in fact underline that there might be an issue similar to > what you described above. > > What is also pretty interesting is the fact that the old (working) > SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios > is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS > 1.8.2 installed in the same location is only half as big: 131.072 bytes. > > I checked at the download site and the 1.8.2 binary version is indeed > not available from http://code.coreboot.org/p/seabios/downloads/. But > both the binary versions for 1.7.5 and 1.8.0 are available and both > are acutually 262.144 bytes in size, so I'd be very surprised if the > 1.8.2 version is really only half that size. By the way, the old > working version (according to the ebuild) was directly downloaded from > the above url and also shows an identical SHA1 digest to that version > available for download there. > > To me this looks as if something is really wrong here. If anybody of > you has access to a 1.8.2 version, could you please confirm whether > there's really that big a size difference between the 1.7.5 and the > 1.8.2 versions? Or is that difference probably attributable to the > missing CONFIG_XEN option? > > Andrew: I havent't gotten around to run the debug version of the > hypervisor again, but if the current suspicion turns out to be true, > there's probably not much value in that anyways. Would you agree? Sadly not. I accept that this issue is possibly fixed in newer SeaBIOS by working around the issue. However, I stand by my original point. *There is no way the guest should be able to get into this situation in the first place*, and its implication of *there is a genuine hypervisor bug which we should track down*, irrespective of whether the issue has been worked around elsehow. ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 23:01 ` Andrew Cooper @ 2015-11-16 23:10 ` Atom2 2015-11-18 22:51 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-16 23:10 UTC (permalink / raw) To: Andrew Cooper, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel Am 17.11.15 um 00:01 schrieb Andrew Cooper: > On 16/11/2015 19:16, Atom2 wrote: >> >> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>>> moment, I thought going down that route first would make a lot of >>>>>> sense >>>>>> as PV guests still do work and one of the differences to HVM domUs is >>>>>> that the former do _not_ require SeaBIOS. Looking at my log files of >>>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to >>>>>> 1.8.2 in >>>>>> the relevant timeframe which obviously had not made it to the >>>>>> hvmloader >>>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of >>>>>> SeaBIOS. >>>>>> >>>>>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that >>>>>> seemed >>>>>> to strongly indicate that there indeed might be an issue with >>>>>> SeaBIOS as >>>>>> this probably was the only variable that had changed from the >>>>>> original >>>>>> install of xen-4.5.1. >>> I recall seeing this way back in Fedora 20 days. I narrowed it down the >>> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >>> >>> Having that fixed in the SeaBIOS package fixed it. >> Hi Konrad, Doug, Andrew (specifically added to this part of the thread)! >> Konrad, you might have found an interesting point. I did have a look >> at the ebuild for the failing version and in there I found the >> following comment: >> ====== comment from ebuild ======= >> # Upstream hasn't released a new binary. We snipe ours from >> Fedora for now. >> # http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz >> ====== end comment from ebuild ======= >> which might in fact underline that there might be an issue similar to >> what you described above. >> >> What is also pretty interesting is the fact that the old (working) >> SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios >> is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS >> 1.8.2 installed in the same location is only half as big: 131.072 bytes. >> >> I checked at the download site and the 1.8.2 binary version is indeed >> not available from http://code.coreboot.org/p/seabios/downloads/. But >> both the binary versions for 1.7.5 and 1.8.0 are available and both >> are acutually 262.144 bytes in size, so I'd be very surprised if the >> 1.8.2 version is really only half that size. By the way, the old >> working version (according to the ebuild) was directly downloaded from >> the above url and also shows an identical SHA1 digest to that version >> available for download there. >> >> To me this looks as if something is really wrong here. If anybody of >> you has access to a 1.8.2 version, could you please confirm whether >> there's really that big a size difference between the 1.7.5 and the >> 1.8.2 versions? Or is that difference probably attributable to the >> missing CONFIG_XEN option? >> >> Andrew: I havent't gotten around to run the debug version of the >> hypervisor again, but if the current suspicion turns out to be true, >> there's probably not much value in that anyways. Would you agree? > Sadly not. Fair enough. I'll try to get things done, hopefully somewhen tomorrow or, in case that doesn't work out, on Wednesday and will send you the requested information. Many thanks for your support, Atom2 > I accept that this issue is possibly fixed in newer SeaBIOS by working > around the issue. > > However, I stand by my original point. *There is no way the guest > should be able to get into this situation in the first place*, and its > implication of *there is a genuine hypervisor bug which we should track > down*, irrespective of whether the issue has been worked around elsehow ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 23:10 ` Atom2 @ 2015-11-18 22:51 ` Atom2 2015-11-18 23:17 ` Andrew Cooper 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-18 22:51 UTC (permalink / raw) To: Andrew Cooper, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel [-- Attachment #1: Type: text/plain, Size: 6662 bytes --] Am 17.11.15 um 00:10 schrieb Atom2: > Am 17.11.15 um 00:01 schrieb Andrew Cooper: >> On 16/11/2015 19:16, Atom2 wrote: >>> >>> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>>>> moment, I thought going down that route first would make a lot of >>>>>>> sense >>>>>>> as PV guests still do work and one of the differences to HVM >>>>>>> domUs is >>>>>>> that the former do _not_ require SeaBIOS. Looking at my log >>>>>>> files of >>>>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to >>>>>>> 1.8.2 in >>>>>>> the relevant timeframe which obviously had not made it to the >>>>>>> hvmloader >>>>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of >>>>>>> SeaBIOS. >>>>>>> >>>>>>> So I re-compiled xen-4.5.1 (obviously now using the installed >>>>>>> SeaBIOS >>>>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that >>>>>>> seemed >>>>>>> to strongly indicate that there indeed might be an issue with >>>>>>> SeaBIOS as >>>>>>> this probably was the only variable that had changed from the >>>>>>> original >>>>>>> install of xen-4.5.1. >>>> I recall seeing this way back in Fedora 20 days. I narrowed it down >>>> the >>>> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >>>> >>>> Having that fixed in the SeaBIOS package fixed it. >>> Hi Konrad, Doug, Andrew (specifically added to this part of the >>> thread)! >>> Konrad, you might have found an interesting point. I did have a look >>> at the ebuild for the failing version and in there I found the >>> following comment: >>> ====== comment from ebuild ======= >>> # Upstream hasn't released a new binary. We snipe ours from >>> Fedora for now. >>> # >>> http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz >>> ====== end comment from ebuild ======= >>> which might in fact underline that there might be an issue similar to >>> what you described above. >>> >>> What is also pretty interesting is the fact that the old (working) >>> SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios >>> is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS >>> 1.8.2 installed in the same location is only half as big: 131.072 >>> bytes. >>> >>> I checked at the download site and the 1.8.2 binary version is indeed >>> not available from http://code.coreboot.org/p/seabios/downloads/. But >>> both the binary versions for 1.7.5 and 1.8.0 are available and both >>> are acutually 262.144 bytes in size, so I'd be very surprised if the >>> 1.8.2 version is really only half that size. By the way, the old >>> working version (according to the ebuild) was directly downloaded from >>> the above url and also shows an identical SHA1 digest to that version >>> available for download there. >>> >>> To me this looks as if something is really wrong here. If anybody of >>> you has access to a 1.8.2 version, could you please confirm whether >>> there's really that big a size difference between the 1.7.5 and the >>> 1.8.2 versions? Or is that difference probably attributable to the >>> missing CONFIG_XEN option? >>> >>> Andrew: I havent't gotten around to run the debug version of the >>> hypervisor again, but if the current suspicion turns out to be true, >>> there's probably not much value in that anyways. Would you agree? >> Sadly not. > Fair enough. I'll try to get things done, hopefully somewhen tomorrow > or, in case that doesn't work out, on Wednesday and will send you the > requested information. > > Many thanks for your support, Atom2 >> I accept that this issue is possibly fixed in newer SeaBIOS by working >> around the issue. >> >> However, I stand by my original point. *There is no way the guest >> should be able to get into this situation in the first place*, and its >> implication of *there is a genuine hypervisor bug which we should track >> down*, irrespective of whether the issue has been worked around elsehow Hi Andrew, as promised I have again tried with a debug build and the results are very mixed. I initially tried to better understand what the debug USE flag actually does in gentoo and my understanding (after reading the so called ebuilds) is now that the XEN hypervisor will be built by adding a gcc option of "debug=y" - and that's what should compile a debug build - right? So I went on and again enabled the debug USE flag plus gdb symbols and rebuilt the hypervisor in the hope that this created a valid and working debug build. It, however, seems there's another problem lurking somewhere which only manifests itself when I boot from the debug build of the hypervisor. The system crashes early on with a DOUBLE FAULT in doIRQ - we have had this already earlier in that thread. I am however a step further as the disass in gdb now seems to provide not just an empty page full of NULL values but rather something that might give you a hint why it crashes that early on: Please see the attached disass file (doIRQ) together with the serial console output (serial.dbg). The old NULL value file was probably because I did not include gdb symbols in the debug build at that time - my bad. So I am at loss why a debug build actually results in a crash early on, but probably Doug could step in here and explain that ... it initially thought that it might have to do with the hardened sources that I am using, but discarded that option because linux does not play any role that early on in the boot process (albeit all lines in the serial log are prefixed with "(XEN)"). Because using a debug build of the hypervisor did not work out, I at least used the debug build of the xen-tools (which includes hvmloader) and run this on the working hypervisor (i.e. the standard, non-debug build) in the hope that this might prove useful. Please find attached the "xl dmesg" from an attempt to start a HVM domU. There's a bit more information included compared to the previous xl dmesg output, but I don't know whether that's of any help. Unfortunately I could not spot any lines "prefixed with [HVM:$DOMID.$VCPUID]" which you had expected. But I assume that's because I was forced to boot from a non-debug build of the hypervisor in order to get the system up at all. So to me it looks as if we are currently stuck - unless you (or Doug) are able to find the root cause of the early crash when using the debug build of the hypervisor. If that is resolved, I could then move on to the next step and hopefully be able to provide the information that you are after. Sorry for not being able to provide better input right now. Thanks Atom2 [-- Attachment #2: serial.dbg --] [-- Type: text/plain, Size: 15119 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=y Wed Nov 18 21:44:54 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot hvm_debug=0xc3f dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.504529] Detected 2394.615 MHz processor. (XEN) [ 1.512357] Initing memory sharing. (XEN) [ 1.516684] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.523531] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.533596] Intel machine check reporting enabled (XEN) [ 1.539144] alt table ffff82d0802e8810 -> ffff82d0802e9830 (XEN) [ 1.545540] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.554027] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.560246] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.566578] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.572817] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.579133] Intel VT-d Snoop Control not enabled. (XEN) [ 1.584680] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.590827] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.596638] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.602347] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.616800] I/O virtualisation enabled (XEN) [ 1.621384] - Dom0 mode: Relaxed (XEN) [ 1.625666] Interrupt remapping enabled (XEN) [ 1.630341] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.636789] ENABLING IO-APIC IRQs (XEN) [ 1.641153] -> Using old ACK method (XEN) [ 1.645893] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.854527] TSC deadline timer enabled (XEN) [ 2.149527] Platform timer is 14.318MHz HPET (XEN) [ 2.154466] 'A' pressed -> using alternative key handling (XEN) [ 2.155163] Allocated console ring of 64 KiB. (XEN) [ 2.156284] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.157337] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.157858] mwait-idle: v0.4 model 0x2a (XEN) [ 2.158376] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.158943] VMX: Supported advanced features: (XEN) [ 2.159463] - APIC MMIO access virtualisation (XEN) [ 2.159983] - APIC TPR shadow (XEN) [ 2.160526] - Extended Page Tables (EPT) (XEN) [ 2.161046] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.161570] - Virtual NMI (XEN) [ 2.162110] - MSR direct-access bitmap (XEN) [ 2.162626] - Unrestricted Guest (XEN) [ 2.163132] HVM: ASIDs enabled. (XEN) [ 2.163672] HVM: VMX enabled (XEN) [ 2.164175] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.164691] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.165873] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.167380] microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.169195] microcode: CPU6 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.170248] Brought up 8 CPUs (XEN) [ 2.176718] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.197373] ACPI sleep modes: S3 (XEN) [ 2.197880] mcheck_poll: Machine check polling timer started. (XEN) [ 2.198412] Dom0 has maximum 792 PIRQs (XEN) [ 2.199006] *** LOADING DOMAIN 0 *** (XEN) [ 2.382223] elf_parse_binary: phdr: paddr=0x1000000 memsz=0x65033b (XEN) [ 2.382784] elf_parse_binary: phdr: paddr=0x1651000 memsz=0x1e5000 (XEN) [ 2.383306] elf_parse_binary: phdr: paddr=0x1836000 memsz=0x98000 (XEN) [ 2.383829] elf_parse_binary: phdr: paddr=0x18ce000 memsz=0x1000 (XEN) [ 2.384387] elf_parse_binary: phdr: paddr=0x18cf000 memsz=0x13c98 (XEN) [ 2.384908] elf_parse_binary: phdr: paddr=0x18e3000 memsz=0x3d000 (XEN) [ 2.385431] elf_parse_binary: phdr: paddr=0x1920000 memsz=0x1120 (XEN) [ 2.385988] elf_parse_binary: phdr: paddr=0x1922000 memsz=0x2de000 (XEN) [ 2.386512] elf_parse_binary: memory: 0x1000000 -> 0x1c00000 (XEN) [ 2.387035] elf_xen_parse_note: GUEST_OS = "linux" (XEN) [ 2.387584] elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) [ 2.388100] elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) [ 2.388616] elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) [ 2.389173] elf_xen_parse_note: ENTRY = 0xffffffff818e31f0 (XEN) [ 2.389692] elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81001000 (XEN) [ 2.390219] elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" (XEN) [ 2.391793] elf_xen_parse_note: SUPPORTED_FEATURES = 0x90d (XEN) [ 2.392311] elf_xen_parse_note: PAE_MODE = "yes" (XEN) [ 2.392826] elf_xen_parse_note: LOADER = "generic" (XEN) [ 2.393597] elf_xen_parse_note: unknown xen elf note (0xd) (XEN) [ 2.394117] elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) [ 2.394630] elf_xen_parse_note: MOD_START_PFN = 0x1 (XEN) [ 2.395180] elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) [ 2.395704] elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) [ 2.396219] elf_xen_addr_calc_check: addresses: (XEN) [ 2.396766] virt_base = 0xffffffff80000000 (XEN) [ 2.397282] elf_paddr_offset = 0x0 (XEN) [ 2.397791] virt_offset = 0xffffffff80000000 (XEN) [ 2.398342] virt_kstart = 0xffffffff81000000 (XEN) [ 2.398858] virt_kend = 0xffffffff81c00000 (XEN) [ 2.399374] virt_entry = 0xffffffff818e31f0 (XEN) [ 2.399923] p2m_base = 0xffffffffffffffff (XEN) [ 2.400439] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 2.400952] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 2.402210] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 2.402717] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 2.403739] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 2.404298] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 2.404807] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 2.405327] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 2.405846] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 2.406364] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 2.406883] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 2.407402] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 2.407920] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 2.408474] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 2.410055] Dom0 has maximum 8 VCPUs (XEN) [ 2.410603] elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8165033b (XEN) [ 2.412981] elf_load_binary: phdr 1 at 0xffffffff81651000 -> 0xffffffff81836000 (XEN) [ 2.414414] elf_load_binary: phdr 2 at 0xffffffff81836000 -> 0xffffffff818ce000 (XEN) [ 2.415548] elf_load_binary: phdr 3 at 0xffffffff818ce000 -> 0xffffffff818cf000 (XEN) [ 2.416597] elf_load_binary: phdr 4 at 0xffffffff818cf000 -> 0xffffffff818e2c98 (XEN) [ 2.417627] elf_load_binary: phdr 5 at 0xffffffff818e3000 -> 0xffffffff81920000 (XEN) [ 2.418723] elf_load_binary: phdr 6 at 0xffffffff81920000 -> 0xffffffff81921120 (XEN) [ 2.419737] elf_load_binary: phdr 7 at 0xffffffff81922000 -> 0xffffffff819dd000 (XEN) [ 2.743635] *** DOUBLE FAULT *** (XEN) [ 2.747762] ----[ Xen-4.5.2 x86_64 debug=y Not tainted ]---- (XEN) [ 2.754520] CPU: 3 (XEN) [ 2.757634] RIP: e008:[<ffff82d08017658c>] do_IRQ+0x15/0x64c (XEN) [ 2.764468] RFLAGS: 0000000000010087 CONTEXT: hypervisor (XEN) [ 2.770790] rax: 0000000000000246 rbx: ffff83080ca9a200 rcx: 0000000000000001 (XEN) [ 2.779543] rdx: ffff82d080318080 rsi: fffffffffffffed4 rdi: ffff83080ca8ed88 (XEN) [ 2.788209] rbp: ffff83080ca8ed78 rsp: ffff83080ca8dcf8 r8: ffff83080ca9d558 (XEN) [ 2.796948] r9: 00000000000001c8 r10: 0000000000000001 r11: 0080000000000000 (XEN) [ 2.805617] r12: ffff83080ca967d0 r13: ffffffffffffffff r14: ffff83080ca88000 (XEN) [ 2.814356] r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000426f0 (XEN) [ 2.823026] cr3: 00000000db69f000 cr2: ffff83080ca8dce8 (XEN) [ 2.829327] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) [ 2.837474] Valid stack range: ffff83080ca8e000-ffff83080ca90000, sp=ffff83080ca8dcf8, tss.esp0=ffff83080ca8ffc0 (XEN) [ 2.848969] No stack overflow detected. Skipping stack trace. (XEN) [ 2.855556] (XEN) [ 2.857949] **************************************** (XEN) [ 2.863754] Panic on CPU 3: (XEN) [ 2.867381] DOUBLE FAULT -- system shutdown (XEN) [ 2.872403] **************************************** (XEN) [ 2.878305] (XEN) [ 2.880632] Reboot in five seconds... [-- Attachment #3: doIRQ --] [-- Type: text/plain, Size: 23069 bytes --] Dump of assembler code for function do_IRQ: 0xffff82d080176577 <+0>: push %rbp 0xffff82d080176578 <+1>: mov %rsp,%rbp 0xffff82d08017657b <+4>: push %r15 0xffff82d08017657d <+6>: push %r14 0xffff82d08017657f <+8>: push %r13 0xffff82d080176581 <+10>: push %r12 0xffff82d080176583 <+12>: push %rbx 0xffff82d080176584 <+13>: lea -0x1058(%rsp),%rsp 0xffff82d08017658c <+21>: orq $0x0,(%rsp) 0xffff82d080176591 <+26>: lea 0x1020(%rsp),%rsp 0xffff82d080176599 <+34>: mov %rdi,%r12 0xffff82d08017659c <+37>: movzbl 0x7c(%rdi),%r13d 0xffff82d0801765a1 <+42>: mov %r13d,%edx 0xffff82d0801765a4 <+45>: lea 0x1c3515(%rip),%rax # 0xffff82d080339ac0 <per_cpu__vector_irq> 0xffff82d0801765ab <+52>: lea (%rax,%rdx,4),%rdx 0xffff82d0801765af <+56>: mov %rsp,%rcx 0xffff82d0801765b2 <+59>: and $0xffffffffffff8000,%rcx 0xffff82d0801765b9 <+66>: mov 0x7ff0(%rcx),%rax 0xffff82d0801765c0 <+73>: mov (%rdx,%rax,1),%esi 0xffff82d0801765c3 <+76>: mov %esi,-0x44(%rbp) 0xffff82d0801765c6 <+79>: lea 0x1c34bb(%rip),%rdx # 0xffff82d080339a88 <per_cpu____irq_regs> 0xffff82d0801765cd <+86>: add %rdx,%rax 0xffff82d0801765d0 <+89>: mov (%rax),%rbx 0xffff82d0801765d3 <+92>: mov %rbx,-0x50(%rbp) 0xffff82d0801765d7 <+96>: mov %rdi,(%rax) 0xffff82d0801765da <+99>: lea 0x1c349f(%rip),%rax # 0xffff82d080339a80 <per_cpu__irq_count> 0xffff82d0801765e1 <+106>: add 0x7ff0(%rcx),%rax 0xffff82d0801765e8 <+113>: addl $0x1,(%rax) 0xffff82d0801765eb <+116>: lea 0x199a8e(%rip),%rdx # 0xffff82d080310080 <irq_stat> 0xffff82d0801765f2 <+123>: mov 0x7fe0(%rcx),%eax 0xffff82d0801765f8 <+129>: shl $0x7,%rax 0xffff82d0801765fc <+133>: addl $0x1,0x4(%rdx,%rax,1) 0xffff82d080176601 <+138>: test %esi,%esi 0xffff82d080176603 <+140>: jns 0xffff82d0801767af <do_IRQ+568> 0xffff82d080176609 <+146>: mov %r13d,%eax 0xffff82d08017660c <+149>: lea 0x1ab3ad(%rip),%rdx # 0xffff82d0803219c0 <direct_apic_vector> 0xffff82d080176613 <+156>: mov (%rdx,%rax,8),%rax 0xffff82d080176617 <+160>: test %rax,%rax 0xffff82d08017661a <+163>: je 0xffff82d080176623 <do_IRQ+172> 0xffff82d08017661c <+165>: callq *%rax 0xffff82d08017661e <+167>: jmpq 0xffff82d080176b7e <do_IRQ+1543> 0xffff82d080176623 <+172>: mov %r13d,%eax 0xffff82d080176626 <+175>: and $0xffffffe0,%eax 0xffff82d080176629 <+178>: sar %eax 0xffff82d08017662b <+180>: add $0x100,%eax 0xffff82d080176630 <+185>: cltq 0xffff82d080176632 <+187>: cmpb $0x0,0x116a4e(%rip) # 0xffff82d08028d087 <x2apic_enabled> 0xffff82d080176639 <+194>: je 0xffff82d080176667 <do_IRQ+240> 0xffff82d08017663b <+196>: shr $0x4,%rax 0xffff82d08017663f <+200>: lea 0x800(%rax),%rcx 0xffff82d080176646 <+207>: rdmsr 0xffff82d080176648 <+209>: mov %rdx,%rcx 0xffff82d08017664b <+212>: shl $0x20,%rcx 0xffff82d08017664f <+216>: or %rcx,%rax 0xffff82d080176652 <+219>: mov %r13d,%ecx 0xffff82d080176655 <+222>: and $0x1f,%ecx 0xffff82d080176658 <+225>: shr %cl,%eax 0xffff82d08017665a <+227>: lea 0xf24c4(%rip),%rbx # 0xffff82d080268b25 0xffff82d080176661 <+234>: test $0x1,%al 0xffff82d080176663 <+236>: je 0xffff82d0801766bb <do_IRQ+324> 0xffff82d080176665 <+238>: jmp 0xffff82d08017668a <do_IRQ+275> 0xffff82d080176667 <+240>: movabs $0xffff82cfffdfb000,%rdx 0xffff82d080176671 <+250>: add %rdx,%rax 0xffff82d080176674 <+253>: mov (%rax),%edx 0xffff82d080176676 <+255>: mov %r13d,%eax 0xffff82d080176679 <+258>: and $0x1f,%eax 0xffff82d08017667c <+261>: lea 0xf24a2(%rip),%rbx # 0xffff82d080268b25 0xffff82d080176683 <+268>: bt %eax,%edx 0xffff82d080176686 <+271>: jae 0xffff82d0801766bb <do_IRQ+324> 0xffff82d080176688 <+273>: jmp 0xffff82d0801766a4 <do_IRQ+301> 0xffff82d08017668a <+275>: mov $0x0,%edx 0xffff82d08017668f <+280>: mov $0x0,%eax 0xffff82d080176694 <+285>: mov $0x80b,%ecx 0xffff82d080176699 <+290>: wrmsr 0xffff82d08017669b <+292>: lea 0xf514b(%rip),%rbx # 0xffff82d08026b7ed 0xffff82d0801766a2 <+299>: jmp 0xffff82d0801766bb <do_IRQ+324> 0xffff82d0801766a4 <+301>: movabs $0xffff82cfffdfb0b0,%rax 0xffff82d0801766ae <+311>: movl $0x0,(%rax) 0xffff82d0801766b4 <+317>: lea 0xf5132(%rip),%rbx # 0xffff82d08026b7ed 0xffff82d0801766bb <+324>: lea -0xe0(%r13),%edi 0xffff82d0801766c2 <+331>: cmp $0xf,%edi 0xffff82d0801766c5 <+334>: ja 0xffff82d0801766d4 <do_IRQ+349> 0xffff82d0801766c7 <+336>: callq 0xffff82d08016f1ea <bogus_8259A_irq> 0xffff82d0801766cc <+341>: test %al,%al 0xffff82d0801766ce <+343>: jne 0xffff82d080176781 <do_IRQ+522> 0xffff82d0801766d4 <+349>: mov %rsp,%rax 0xffff82d0801766d7 <+352>: and $0xffffffffffff8000,%rax 0xffff82d0801766dd <+358>: mov 0x7fe0(%rax),%esi 0xffff82d0801766e3 <+364>: mov %rbx,%r8 0xffff82d0801766e6 <+367>: mov -0x44(%rbp),%r12d 0xffff82d0801766ea <+371>: mov %r12d,%ecx 0xffff82d0801766ed <+374>: mov %r13d,%edx 0xffff82d0801766f0 <+377>: lea 0x103971(%rip),%rdi # 0xffff82d08027a068 0xffff82d0801766f7 <+384>: mov $0x0,%eax 0xffff82d0801766fc <+389>: callq 0xffff82d080146cfb <printk> 0xffff82d080176701 <+394>: mov 0x117108(%rip),%rdx # 0xffff82d08028d810 <irq_desc> 0xffff82d080176708 <+401>: not %r12d 0xffff82d08017670b <+404>: cmp 0x11710a(%rip),%r12d # 0xffff82d08028d81c <nr_irqs> 0xffff82d080176712 <+411>: jae 0xffff82d080176781 <do_IRQ+522> 0xffff82d080176714 <+413>: movslq %r12d,%rbx 0xffff82d080176717 <+416>: mov %rbx,%rax 0xffff82d08017671a <+419>: shl $0x8,%rax 0xffff82d08017671e <+423>: lea (%rdx,%rax,1),%rbx 0xffff82d080176722 <+427>: cmpq $0x0,0x8(%rbx) 0xffff82d080176727 <+432>: je 0xffff82d080176781 <do_IRQ+522> 0xffff82d080176729 <+434>: lea 0x24(%rbx),%r14 0xffff82d08017672d <+438>: mov %r14,%rdi 0xffff82d080176730 <+441>: callq 0xffff82d08012e8cd <_spin_lock> 0xffff82d080176735 <+446>: sub $0x8,%rsp 0xffff82d080176739 <+450>: mov 0x40(%rbx),%rcx 0xffff82d08017673d <+454>: mov 0x38(%rbx),%rdx 0xffff82d080176741 <+458>: mov 0x68(%rbx),%rax 0xffff82d080176745 <+462>: mov (%rbx),%esi 0xffff82d080176747 <+464>: push %rsi 0xffff82d080176748 <+465>: mov 0x8(%rbx),%rsi 0xffff82d08017674c <+469>: pushq (%rsi) 0xffff82d08017674e <+471>: movswl 0x32(%rbx),%esi 0xffff82d080176752 <+475>: push %rsi 0xffff82d080176753 <+476>: movswl 0x30(%rbx),%r9d 0xffff82d080176758 <+481>: mov (%rcx),%r8 0xffff82d08017675b <+484>: mov (%rdx),%rcx 0xffff82d08017675e <+487>: mov (%rax),%rdx 0xffff82d080176761 <+490>: mov %r12d,%esi 0xffff82d080176764 <+493>: lea 0x103935(%rip),%rdi # 0xffff82d08027a0a0 0xffff82d08017676b <+500>: mov $0x0,%eax 0xffff82d080176770 <+505>: callq 0xffff82d080146cfb <printk> 0xffff82d080176775 <+510>: add $0x20,%rsp 0xffff82d080176779 <+514>: mov %r14,%rdi 0xffff82d08017677c <+517>: callq 0xffff82d08012ea4f <_spin_unlock> 0xffff82d080176781 <+522>: cmpl $0x0,0x113d34(%rip) # 0xffff82d08028a4bc <tb_init_done> 0xffff82d080176788 <+529>: je 0xffff82d080176b7e <do_IRQ+1543> 0xffff82d08017678e <+535>: mov %r13d,-0x3c(%rbp) 0xffff82d080176792 <+539>: lea -0x3c(%rbp),%rcx 0xffff82d080176796 <+543>: mov $0x4,%edx 0xffff82d08017679b <+548>: mov $0x1,%esi 0xffff82d0801767a0 <+553>: mov $0x802007,%edi 0xffff82d0801767a5 <+558>: callq 0xffff82d08013369f <__trace_var> 0xffff82d0801767aa <+563>: jmpq 0xffff82d080176b7e <do_IRQ+1543> 0xffff82d0801767af <+568>: movslq -0x44(%rbp),%r15 0xffff82d0801767b3 <+572>: mov %r15,%r14 0xffff82d0801767b6 <+575>: shl $0x8,%r14 0xffff82d0801767ba <+579>: mov %r14,%rbx 0xffff82d0801767bd <+582>: add 0x11704c(%rip),%rbx # 0xffff82d08028d810 <irq_desc> 0xffff82d0801767c4 <+589>: lea 0x24(%rbx),%rax 0xffff82d0801767c8 <+593>: mov %rax,-0x58(%rbp) 0xffff82d0801767cc <+597>: mov %rax,%rdi 0xffff82d0801767cf <+600>: callq 0xffff82d08012e8cd <_spin_lock> 0xffff82d0801767d4 <+605>: mov 0x8(%rbx),%rax 0xffff82d0801767d8 <+609>: mov %rbx,%rdi 0xffff82d0801767db <+612>: callq *0x28(%rax) 0xffff82d0801767de <+615>: mov (%rbx),%edx 0xffff82d0801767e0 <+617>: test $0x10,%dl 0xffff82d0801767e3 <+620>: je 0xffff82d080176aca <do_IRQ+1363> 0xffff82d0801767e9 <+626>: cmpq $0x0,0x1ab9e7(%rip) # 0xffff82d0803221d8 <irq_ratelimit_timer+24> 0xffff82d0801767f1 <+634>: je 0xffff82d0801768b4 <do_IRQ+829> 0xffff82d0801767f7 <+640>: mov 0x78(%rbx),%eax 0xffff82d0801767fa <+643>: lea 0x1(%rax),%edx 0xffff82d0801767fd <+646>: mov %edx,0x78(%rbx) 0xffff82d080176800 <+649>: cmp 0x117002(%rip),%eax # 0xffff82d08028d808 <irq_ratelimit_threshold> 0xffff82d080176806 <+655>: jb 0xffff82d0801768b4 <do_IRQ+829> 0xffff82d08017680c <+661>: callq 0xffff82d080190b82 <get_s_time> 0xffff82d080176811 <+666>: mov %rax,%r12 0xffff82d080176814 <+669>: mov 0x70(%rbx),%rax 0xffff82d080176818 <+673>: add $0x989680,%rax 0xffff82d08017681e <+679>: cmp %rax,%r12 0xffff82d080176821 <+682>: jge 0xffff82d0801768a9 <do_IRQ+818> 0xffff82d080176827 <+688>: mov 0x8(%rbx),%rax 0xffff82d08017682b <+692>: mov %rbx,%rdi 0xffff82d08017682e <+695>: callq *0x20(%rax) 0xffff82d080176831 <+698>: lea 0x80(%rbx),%r14 0xffff82d080176838 <+705>: cmp 0x80(%rbx),%r14 0xffff82d08017683f <+712>: jne 0xffff82d080176b60 <do_IRQ+1513> 0xffff82d080176845 <+718>: lea 0x12b2f4(%rip),%rdi # 0xffff82d0802a1b40 <irq_ratelimit_lock> 0xffff82d08017684c <+725>: callq 0xffff82d08012e8cd <_spin_lock> 0xffff82d080176851 <+730>: lea 0x12c668(%rip),%rax # 0xffff82d0802a2ec0 <irq_ratelimit_list> 0xffff82d080176858 <+737>: cmp %rax,(%rax) 0xffff82d08017685b <+740>: jne 0xffff82d080176871 <do_IRQ+762> 0xffff82d08017685d <+742>: lea 0x989680(%r12),%rsi 0xffff82d080176865 <+750>: lea 0x1ab954(%rip),%rdi # 0xffff82d0803221c0 <irq_ratelimit_timer> 0xffff82d08017686c <+757>: callq 0xffff82d080132023 <set_timer> 0xffff82d080176871 <+762>: mov 0x12c648(%rip),%rax # 0xffff82d0802a2ec0 <irq_ratelimit_list> 0xffff82d080176878 <+769>: mov %r14,0x8(%rax) 0xffff82d08017687c <+773>: mov %rax,0x80(%rbx) 0xffff82d080176883 <+780>: lea 0x12c636(%rip),%rax # 0xffff82d0802a2ec0 <irq_ratelimit_list> 0xffff82d08017688a <+787>: mov %rax,0x88(%rbx) 0xffff82d080176891 <+794>: mov %r14,0x12c628(%rip) # 0xffff82d0802a2ec0 <irq_ratelimit_list> 0xffff82d080176898 <+801>: lea 0x12b2a1(%rip),%rdi # 0xffff82d0802a1b40 <irq_ratelimit_lock> 0xffff82d08017689f <+808>: callq 0xffff82d08012ea4f <_spin_unlock> 0xffff82d0801768a4 <+813>: jmpq 0xffff82d080176b60 <do_IRQ+1513> 0xffff82d0801768a9 <+818>: movl $0x0,0x78(%rbx) 0xffff82d0801768b0 <+825>: mov %r12,0x70(%rbx) 0xffff82d0801768b4 <+829>: movl $0x0,-0x60(%rbp) 0xffff82d0801768bb <+836>: cmpl $0x0,0x113bfa(%rip) # 0xffff82d08028a4bc <tb_init_done> 0xffff82d0801768c2 <+843>: je 0xffff82d0801768c9 <do_IRQ+850> 0xffff82d0801768c4 <+845>: rdtsc 0xffff82d0801768c6 <+847>: mov %eax,-0x60(%rbp) 0xffff82d0801768c9 <+850>: mov %r14,%rdi 0xffff82d0801768cc <+853>: add 0x116f3d(%rip),%rdi # 0xffff82d08028d810 <irq_desc> 0xffff82d0801768d3 <+860>: mov 0x18(%rdi),%r12 0xffff82d0801768d7 <+864>: lea 0x1c2ea2(%rip),%rdx # 0xffff82d080339780 <per_cpu__pending_eoi> 0xffff82d0801768de <+871>: mov %rsp,%rax 0xffff82d0801768e1 <+874>: and $0xffffffffffff8000,%rax 0xffff82d0801768e7 <+880>: mov 0x7ff0(%rax),%rcx 0xffff82d0801768ee <+887>: lea 0x1c3193(%rip),%rax # 0xffff82d080339a88 <per_cpu____irq_regs> 0xffff82d0801768f5 <+894>: mov (%rax,%rcx,1),%rax 0xffff82d0801768f9 <+898>: movzbl 0x7c(%rax),%esi 0xffff82d0801768fd <+902>: cmpb $0x0,(%r12) 0xffff82d080176902 <+907>: jne 0xffff82d08017692d <do_IRQ+950> 0xffff82d080176904 <+909>: cmpb $0x2,0x3(%r12) 0xffff82d08017690a <+915>: je 0xffff82d08017690e <do_IRQ+919> 0xffff82d08017690c <+917>: ud2 0xffff82d08017690e <+919>: testb $0x2,(%rdi) 0xffff82d080176911 <+922>: jne 0xffff82d080176915 <do_IRQ+926> 0xffff82d080176913 <+924>: ud2 0xffff82d080176915 <+926>: mov 0x8(%rdi),%rax 0xffff82d080176919 <+930>: mov 0x30(%rax),%rax 0xffff82d08017691d <+934>: test %rax,%rax 0xffff82d080176920 <+937>: je 0xffff82d080176a8f <do_IRQ+1304> 0xffff82d080176926 <+943>: callq *%rax 0xffff82d080176928 <+945>: jmpq 0xffff82d080176a8f <do_IRQ+1304> 0xffff82d08017692d <+950>: cmpb $0x2,0x3(%r12) 0xffff82d080176933 <+956>: jne 0xffff82d0801769b1 <do_IRQ+1082> 0xffff82d080176935 <+958>: add %rcx,%rdx 0xffff82d080176938 <+961>: movzbl 0x2ff(%rdx),%ecx 0xffff82d08017693f <+968>: movzbl %cl,%eax 0xffff82d080176942 <+971>: test %eax,%eax 0xffff82d080176944 <+973>: je 0xffff82d08017695d <do_IRQ+998> 0xffff82d080176946 <+975>: movzbl %cl,%edi 0xffff82d080176949 <+978>: movzbl -0x1(%rdx,%rdi,4),%edi 0xffff82d08017694e <+983>: cmp %edi,%esi 0xffff82d080176950 <+985>: ja 0xffff82d080176954 <do_IRQ+989> 0xffff82d080176952 <+987>: ud2 0xffff82d080176954 <+989>: cmp $0xbe,%eax 0xffff82d080176959 <+994>: jle 0xffff82d08017695d <do_IRQ+998> 0xffff82d08017695b <+996>: ud2 0xffff82d08017695d <+998>: movzbl %cl,%eax 0xffff82d080176960 <+1001>: lea (%rdx,%rax,4),%rdi 0xffff82d080176964 <+1005>: mov -0x44(%rbp),%eax 0xffff82d080176967 <+1008>: and $0x7fffff,%eax 0xffff82d08017696c <+1013>: add %eax,%eax 0xffff82d08017696e <+1015>: mov (%rdi),%r8d 0xffff82d080176971 <+1018>: and $0xff000001,%r8d 0xffff82d080176978 <+1025>: or %r8d,%eax 0xffff82d08017697b <+1028>: mov %eax,(%rdi) 0xffff82d08017697d <+1030>: mov %sil,0x3(%rdi) 0xffff82d080176981 <+1034>: and $0xfffffffe,%eax 0xffff82d080176984 <+1037>: mov %al,(%rdi) 0xffff82d080176986 <+1039>: add $0x1,%ecx 0xffff82d080176989 <+1042>: mov %cl,0x2ff(%rdx) 0xffff82d08017698f <+1048>: mov %rsp,%rax 0xffff82d080176992 <+1051>: and $0xffffffffffff8000,%rax 0xffff82d080176998 <+1057>: mov 0x7fe0(%rax),%eax 0xffff82d08017699e <+1063>: mov 0x8(%r12),%rdx 0xffff82d0801769a3 <+1068>: cmp 0x113057(%rip),%eax # 0xffff82d080289a00 <nr_cpu_ids> 0xffff82d0801769a9 <+1074>: jb 0xffff82d0801769ad <do_IRQ+1078> 0xffff82d0801769ab <+1076>: ud2 0xffff82d0801769ad <+1078>: lock bts %eax,(%rdx) 0xffff82d0801769b1 <+1082>: cmpb $0x0,(%r12) 0xffff82d0801769b6 <+1087>: je 0xffff82d080176a50 <do_IRQ+1241> 0xffff82d0801769bc <+1093>: mov $0x0,%r13d 0xffff82d0801769c2 <+1099>: movslq %r13d,%rax 0xffff82d0801769c5 <+1102>: mov 0x40(%r12,%rax,8),%rbx 0xffff82d0801769ca <+1107>: lea 0xb70(%rbx),%rdi 0xffff82d0801769d1 <+1114>: mov %r15,%rsi 0xffff82d0801769d4 <+1117>: callq 0xffff82d08013ebb6 <radix_tree_lookup> 0xffff82d0801769d9 <+1122>: test %rax,%rax 0xffff82d0801769dc <+1125>: je 0xffff82d0801769f2 <do_IRQ+1147> 0xffff82d0801769de <+1127>: mov %rax,%rdx 0xffff82d0801769e1 <+1130>: and $0x3,%edx 0xffff82d0801769e4 <+1133>: cmp $0x2,%rdx 0xffff82d0801769e8 <+1137>: je 0xffff82d0801769ec <do_IRQ+1141> 0xffff82d0801769ea <+1139>: ud2 0xffff82d0801769ec <+1141>: shr $0x2,%rax 0xffff82d0801769f0 <+1145>: jmp 0xffff82d0801769f7 <do_IRQ+1152> 0xffff82d0801769f2 <+1147>: mov $0x0,%eax 0xffff82d0801769f7 <+1152>: movslq %eax,%rsi 0xffff82d0801769fa <+1155>: lea 0xe0(%rbx),%rdi 0xffff82d080176a01 <+1162>: callq 0xffff82d08013ebb6 <radix_tree_lookup> 0xffff82d080176a06 <+1167>: mov %rax,%r14 0xffff82d080176a09 <+1170>: cmpb $0x0,0x3(%r12) 0xffff82d080176a0f <+1176>: je 0xffff82d080176a24 <do_IRQ+1197> 0xffff82d080176a11 <+1178>: mov $0x1,%eax 0xffff82d080176a16 <+1183>: xchg %al,0x6(%r14) 0xffff82d080176a1a <+1187>: test %al,%al 0xffff82d080176a1c <+1189>: jne 0xffff82d080176a24 <do_IRQ+1197> 0xffff82d080176a1e <+1191>: addb $0x1,0x1(%r12) 0xffff82d080176a24 <+1197>: mov %r14,%rsi 0xffff82d080176a27 <+1200>: mov %rbx,%rdi 0xffff82d080176a2a <+1203>: callq 0xffff82d08014d73f <hvm_do_IRQ_dpci> 0xffff82d080176a2f <+1208>: test %eax,%eax 0xffff82d080176a31 <+1210>: jne 0xffff82d080176a3e <do_IRQ+1223> 0xffff82d080176a33 <+1212>: mov %r14,%rsi 0xffff82d080176a36 <+1215>: mov %rbx,%rdi 0xffff82d080176a39 <+1218>: callq 0xffff82d080108647 <send_guest_pirq> 0xffff82d080176a3e <+1223>: add $0x1,%r13d 0xffff82d080176a42 <+1227>: movzbl (%r12),%eax 0xffff82d080176a47 <+1232>: cmp %eax,%r13d 0xffff82d080176a4a <+1235>: jl 0xffff82d0801769c2 <do_IRQ+1099> 0xffff82d080176a50 <+1241>: cmpb $0x0,0x3(%r12) 0xffff82d080176a56 <+1247>: je 0xffff82d080176a8f <do_IRQ+1304> 0xffff82d080176a58 <+1249>: add $0x10,%r12 0xffff82d080176a5c <+1253>: mov %r12,%rdi 0xffff82d080176a5f <+1256>: callq 0xffff82d080132231 <stop_timer> 0xffff82d080176a64 <+1261>: mov %rsp,%rax 0xffff82d080176a67 <+1264>: and $0xffffffffffff8000,%rax 0xffff82d080176a6d <+1270>: mov 0x7fe0(%rax),%esi 0xffff82d080176a73 <+1276>: mov %r12,%rdi 0xffff82d080176a76 <+1279>: callq 0xffff82d0801323d3 <migrate_timer> 0xffff82d080176a7b <+1284>: callq 0xffff82d080190b82 <get_s_time> 0xffff82d080176a80 <+1289>: lea 0xf4240(%rax),%rsi 0xffff82d080176a87 <+1296>: mov %r12,%rdi 0xffff82d080176a8a <+1299>: callq 0xffff82d080132023 <set_timer> 0xffff82d080176a8f <+1304>: cmpl $0x0,0x113a26(%rip) # 0xffff82d08028a4bc <tb_init_done> 0xffff82d080176a96 <+1311>: je 0xffff82d080176b75 <do_IRQ+1534> 0xffff82d080176a9c <+1317>: mov -0x44(%rbp),%eax 0xffff82d080176a9f <+1320>: mov %eax,-0x3c(%rbp) 0xffff82d080176aa2 <+1323>: mov -0x60(%rbp),%eax 0xffff82d080176aa5 <+1326>: mov %eax,-0x38(%rbp) 0xffff82d080176aa8 <+1329>: rdtsc 0xffff82d080176aaa <+1331>: mov %eax,-0x34(%rbp) 0xffff82d080176aad <+1334>: lea -0x3c(%rbp),%rcx 0xffff82d080176ab1 <+1338>: mov $0xc,%edx 0xffff82d080176ab6 <+1343>: mov $0x1,%esi 0xffff82d080176abb <+1348>: mov $0x802008,%edi 0xffff82d080176ac0 <+1353>: callq 0xffff82d08013369f <__trace_var> 0xffff82d080176ac5 <+1358>: jmpq 0xffff82d080176b75 <do_IRQ+1534> 0xffff82d080176aca <+1363>: mov %edx,%eax 0xffff82d080176acc <+1365>: and $0xfffffff7,%eax 0xffff82d080176acf <+1368>: test $0x3,%dl 0xffff82d080176ad2 <+1371>: je 0xffff82d080176ade <do_IRQ+1383> 0xffff82d080176ad4 <+1373>: or $0x4,%eax 0xffff82d080176ad7 <+1376>: mov %eax,(%rbx) 0xffff82d080176ad9 <+1378>: jmpq 0xffff82d080176b60 <do_IRQ+1513> 0xffff82d080176ade <+1383>: or $0x5,%eax 0xffff82d080176ae1 <+1386>: mov 0x18(%rbx),%r14 0xffff82d080176ae5 <+1390>: lea -0x3c(%rbp),%rcx 0xffff82d080176ae9 <+1394>: mov %rcx,-0x60(%rbp) 0xffff82d080176aed <+1398>: and $0xfffffffb,%eax 0xffff82d080176af0 <+1401>: mov %eax,(%rbx) 0xffff82d080176af2 <+1403>: mov -0x58(%rbp),%rdi 0xffff82d080176af6 <+1407>: callq 0xffff82d08012ea7f <_spin_unlock_irq> 0xffff82d080176afb <+1412>: mov $0x0,%r15d 0xffff82d080176b01 <+1418>: cmpl $0x0,0x1139b4(%rip) # 0xffff82d08028a4bc <tb_init_done> 0xffff82d080176b08 <+1425>: je 0xffff82d080176b0f <do_IRQ+1432> 0xffff82d080176b0a <+1427>: rdtsc 0xffff82d080176b0c <+1429>: mov %eax,%r15d 0xffff82d080176b0f <+1432>: mov 0x10(%r14),%rsi 0xffff82d080176b13 <+1436>: mov %r12,%rdx 0xffff82d080176b16 <+1439>: mov -0x44(%rbp),%edi 0xffff82d080176b19 <+1442>: callq *(%r14) 0xffff82d080176b1c <+1445>: cmpl $0x0,0x113999(%rip) # 0xffff82d08028a4bc <tb_init_done> 0xffff82d080176b23 <+1452>: je 0xffff82d080176b4c <do_IRQ+1493> 0xffff82d080176b25 <+1454>: mov -0x44(%rbp),%eax 0xffff82d080176b28 <+1457>: mov %eax,-0x3c(%rbp) 0xffff82d080176b2b <+1460>: mov %r15d,-0x38(%rbp) 0xffff82d080176b2f <+1464>: rdtsc 0xffff82d080176b31 <+1466>: mov %eax,-0x34(%rbp) 0xffff82d080176b34 <+1469>: mov -0x60(%rbp),%rcx 0xffff82d080176b38 <+1473>: mov $0xc,%edx 0xffff82d080176b3d <+1478>: mov $0x1,%esi 0xffff82d080176b42 <+1483>: mov $0x802008,%edi 0xffff82d080176b47 <+1488>: callq 0xffff82d08013369f <__trace_var> 0xffff82d080176b4c <+1493>: mov -0x58(%rbp),%rdi 0xffff82d080176b50 <+1497>: callq 0xffff82d08012e936 <_spin_lock_irq> 0xffff82d080176b55 <+1502>: mov (%rbx),%eax 0xffff82d080176b57 <+1504>: test $0x4,%al 0xffff82d080176b59 <+1506>: jne 0xffff82d080176aed <do_IRQ+1398> 0xffff82d080176b5b <+1508>: and $0xfffffffe,%eax 0xffff82d080176b5e <+1511>: mov %eax,(%rbx) 0xffff82d080176b60 <+1513>: mov 0x8(%rbx),%rax 0xffff82d080176b64 <+1517>: mov 0x30(%rax),%rax 0xffff82d080176b68 <+1521>: test %rax,%rax 0xffff82d080176b6b <+1524>: je 0xffff82d080176b75 <do_IRQ+1534> 0xffff82d080176b6d <+1526>: mov %r13d,%esi 0xffff82d080176b70 <+1529>: mov %rbx,%rdi 0xffff82d080176b73 <+1532>: callq *%rax 0xffff82d080176b75 <+1534>: mov -0x58(%rbp),%rdi 0xffff82d080176b79 <+1538>: callq 0xffff82d08012ea4f <_spin_unlock> 0xffff82d080176b7e <+1543>: mov %rsp,%rdx 0xffff82d080176b81 <+1546>: and $0xffffffffffff8000,%rdx 0xffff82d080176b88 <+1553>: lea 0x1994f1(%rip),%rcx # 0xffff82d080310080 <irq_stat> 0xffff82d080176b8f <+1560>: mov 0x7fe0(%rdx),%eax 0xffff82d080176b95 <+1566>: shl $0x7,%rax 0xffff82d080176b99 <+1570>: subl $0x1,0x4(%rcx,%rax,1) 0xffff82d080176b9e <+1575>: lea 0x1c2ee3(%rip),%rax # 0xffff82d080339a88 <per_cpu____irq_regs> 0xffff82d080176ba5 <+1582>: mov 0x7ff0(%rdx),%rdx 0xffff82d080176bac <+1589>: mov -0x50(%rbp),%rcx 0xffff82d080176bb0 <+1593>: mov %rcx,(%rax,%rdx,1) 0xffff82d080176bb4 <+1597>: lea -0x28(%rbp),%rsp 0xffff82d080176bb8 <+1601>: pop %rbx 0xffff82d080176bb9 <+1602>: pop %r12 0xffff82d080176bbb <+1604>: pop %r13 0xffff82d080176bbd <+1606>: pop %r14 0xffff82d080176bbf <+1608>: pop %r15 0xffff82d080176bc1 <+1610>: pop %rbp 0xffff82d080176bc2 <+1611>: retq End of assembler dump. [-- Attachment #4: xl.dmesg --] [-- Type: text/plain, Size: 35402 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=n Wed Nov 18 22:55:24 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all com1=115200,8n1,0x3f8,4 console=com1,vga console_timestamps=boot hvm_debug=0xc3f dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 1.444848] Detected 2394.579 MHz processor. (XEN) [ 1.452444] Initing memory sharing. (XEN) [ 1.456772] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 1.463620] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 1.473725] Intel machine check reporting enabled (XEN) [ 1.479272] alt table ffff82d0802cfa90 -> ffff82d0802d0bd0 (XEN) [ 1.485705] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 1.494189] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 1.500368] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 1.506774] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 1.513009] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 1.519367] Intel VT-d Snoop Control not enabled. (XEN) [ 1.524910] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 1.531173] Intel VT-d Queued Invalidation enabled. (XEN) [ 1.536893] Intel VT-d Interrupt Remapping enabled. (XEN) [ 1.542605] Intel VT-d Shared EPT tables not enabled. (XEN) [ 1.556868] I/O virtualisation enabled (XEN) [ 1.561576] - Dom0 mode: Relaxed (XEN) [ 1.565734] Interrupt remapping enabled (XEN) [ 1.570408] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 1.576852] ENABLING IO-APIC IRQs (XEN) [ 1.581081] -> Using old ACK method (XEN) [ 1.585804] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.794848] TSC deadline timer enabled (XEN) [ 2.799471] Platform timer is 14.318MHz HPET (XEN) [ 2.804268] 'A' pressed -> using alternative key handling (XEN) [ 2.804963] Allocated console ring of 64 KiB. (XEN) [ 2.806146] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.807391] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 2.807944] mwait-idle: v0.4 model 0x2a (XEN) [ 2.808461] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 2.808995] VMX: Supported advanced features: (XEN) [ 2.809545] - APIC MMIO access virtualisation (XEN) [ 2.810066] - APIC TPR shadow (XEN) [ 2.810580] - Extended Page Tables (EPT) (XEN) [ 2.811128] - Virtual-Processor Identifiers (VPID) (XEN) [ 2.811652] - Virtual NMI (XEN) [ 2.812163] - MSR direct-access bitmap (XEN) [ 2.812711] - Unrestricted Guest (XEN) [ 2.813218] HVM: ASIDs enabled. (XEN) [ 2.813724] HVM: VMX enabled (XEN) [ 2.814263] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 2.814779] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 2.815929] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.816967] Brought up 8 CPUs (XEN) [ 2.817487] microcode: CPU5 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.824356] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 2.824874] microcode: CPU7 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 2.846051] ACPI sleep modes: S3 (XEN) [ 2.846556] mcheck_poll: Machine check polling timer started. (XEN) [ 2.847083] Dom0 has maximum 792 PIRQs (XEN) [ 2.847668] *** LOADING DOMAIN 0 *** (XEN) [ 3.029255] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 3.029805] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 3.031289] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 3.031796] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 3.032816] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 3.033377] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 3.033886] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 3.034406] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 3.034926] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 3.035444] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 3.035964] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 3.036485] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 3.037003] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 3.037559] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 3.038892] Dom0 has maximum 8 VCPUs (XEN) [ 6.204144] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 6.212447] Std. Loglevel: All (XEN) [ 6.212988] Guest Loglevel: All (XEN) [ 6.213492] Xen is relinquishing VGA console. (XEN) [ 6.214566] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) [ 6.214605] Freed 316kB init memory. (XEN) [ 6.214613] '0' pressed -> dumping Dom0's registers (XEN) [ 6.214616] *** Dumping Dom0 vcpu#0 state: *** (XEN) [ 6.214619] RIP: e033:[<ffffffff818e31f0>] (XEN) [ 6.214621] RFLAGS: 0000000000000200 EM: 1 CONTEXT: pv guest (d0v0) (XEN) [ 6.214624] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214626] rdx: 0000000000000000 rsi: ffffffff82400000 rdi: 0000000000000000 (XEN) [ 6.214628] rbp: 0000000000000000 rsp: ffffffff82419000 r8: 0000000000000000 (XEN) [ 6.214630] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214632] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214633] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214635] cr3: 0000000802401000 cr2: 0000000000000000 (XEN) [ 6.214637] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) [ 6.214639] Guest stack trace from rsp=ffffffff82419000: (XEN) [ 6.214640] Stack empty. (XEN) [ 6.214649] *** Dumping Dom0 vcpu#1 state: *** (XEN) [ 6.214652] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214654] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v1) (XEN) [ 6.214658] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214660] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214662] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214665] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214667] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214669] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214671] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214674] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214707] *** Dumping Dom0 vcpu#2 state: *** (XEN) [ 6.214710] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214712] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v2) (XEN) [ 6.214715] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214717] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214719] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214720] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214722] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214723] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214725] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214727] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214733] *** Dumping Dom0 vcpu#3 state: *** (XEN) [ 6.214735] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214737] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v3) (XEN) [ 6.214740] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214742] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214743] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214745] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214747] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214748] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214750] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214752] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214780] *** Dumping Dom0 vcpu#4 state: *** (XEN) [ 6.214783] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214785] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v4) (XEN) [ 6.214788] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214790] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214791] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214793] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214795] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214797] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214799] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214800] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214807] *** Dumping Dom0 vcpu#5 state: *** (XEN) [ 6.214809] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214810] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v5) (XEN) [ 6.214813] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214815] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214816] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214818] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214820] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214821] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214823] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214824] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214853] *** Dumping Dom0 vcpu#6 state: *** (XEN) [ 6.214856] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214858] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v6) (XEN) [ 6.214861] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214863] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214864] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214866] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214868] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214869] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214871] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214873] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.214879] *** Dumping Dom0 vcpu#7 state: *** (XEN) [ 6.214881] RIP: 0000:[<0000000000000000>] (XEN) [ 6.214882] RFLAGS: 0000000000000000 EM: 1 CONTEXT: pv guest (d0v7) (XEN) [ 6.214885] rax: 0000000000000000 rbx: 0000000000000000 rcx: 0000000000000000 (XEN) [ 6.214887] rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 (XEN) [ 6.214888] rbp: 0000000000000000 rsp: 0000000000000000 r8: 0000000000000000 (XEN) [ 6.214890] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 6.214892] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 6.214893] r15: 0000000000000000 cr0: 0000000000000000 cr4: 0000000000002660 (XEN) [ 6.214895] cr3: 0000000000000000 cr2: 0000000000000000 (XEN) [ 6.214897] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 (XEN) [ 6.470939] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.470943] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) [ 6.470947] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) [ 6.470950] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.470954] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) [ 6.470957] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.470960] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.555997] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.556004] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080cab3000 to 0xffffffff81646d10. (XEN) [ 6.556009] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080cab3080 to 0xffffffff81648e70. (XEN) [ 6.556014] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.556019] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000175 from 0xffff83080cab7fc0 to 0x0000000000000000. (XEN) [ 6.556024] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.556029] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.556330] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.556335] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000082 from 0xffff83080caa3000 to 0xffffffff81646d10. (XEN) [ 6.556338] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000083 from 0xffff83080caa3080 to 0xffffffff81648e70. (XEN) [ 6.556342] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.556345] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000175 from 0xffff83080caa7fc0 to 0x0000000000000000. (XEN) [ 6.556348] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.556352] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.556648] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.556653] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca93000 to 0xffffffff81646d10. (XEN) [ 6.556657] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca93080 to 0xffffffff81648e70. (XEN) [ 6.556660] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.556663] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca97fc0 to 0x0000000000000000. (XEN) [ 6.556667] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.556670] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.556942] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.556947] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca83000 to 0xffffffff81646d10. (XEN) [ 6.556950] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca83080 to 0xffffffff81648e70. (XEN) [ 6.556953] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.556957] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca87fc0 to 0x0000000000000000. (XEN) [ 6.556960] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.556963] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.557196] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.557200] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063f3000 to 0xffffffff81646d10. (XEN) [ 6.557204] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063f3080 to 0xffffffff81648e70. (XEN) [ 6.557207] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.557210] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000175 from 0xffff8308063f7fc0 to 0x0000000000000000. (XEN) [ 6.557213] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.557216] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.557430] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.557464] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063eb000 to 0xffffffff81646d10. (XEN) [ 6.557468] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063eb080 to 0xffffffff81648e70. (XEN) [ 6.557471] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.557475] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000175 from 0xffff8308063effc0 to 0x0000000000000000. (XEN) [ 6.557478] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.557481] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.557678] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 6.557682] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063db000 to 0xffffffff81646d10. (XEN) [ 6.557685] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063db080 to 0xffffffff81648e70. (XEN) [ 6.557688] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 6.557691] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000175 from 0xffff8308063dffc0 to 0x0000000000000000. (XEN) [ 6.557695] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000176 from 0xffff82d080235550 to 0xffffffff81648cf0. (XEN) [ 6.557698] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 7.700727] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 7.700730] PCI add device 0000:00:00.0 (XEN) [ 7.700921] PCI add device 0000:00:01.0 (XEN) [ 7.701104] PCI add device 0000:00:01.1 (XEN) [ 7.701334] PCI add device 0000:00:02.0 (XEN) [ 7.701539] PCI add device 0000:00:06.0 (XEN) [ 7.701824] PCI add device 0000:00:16.0 (XEN) [ 7.702109] PCI add device 0000:00:19.0 (XEN) [ 7.702406] PCI add device 0000:00:1a.0 (XEN) [ 7.702670] PCI add device 0000:00:1b.0 (XEN) [ 7.702950] PCI add device 0000:00:1c.0 (XEN) [ 7.703213] PCI add device 0000:00:1c.4 (XEN) [ 7.703469] PCI add device 0000:00:1c.6 (XEN) [ 7.703766] PCI add device 0000:00:1d.0 (XEN) [ 7.703941] PCI add device 0000:00:1e.0 (XEN) [ 7.704193] PCI add device 0000:00:1f.0 (XEN) [ 7.704489] PCI add device 0000:00:1f.2 (XEN) [ 7.704671] PCI add device 0000:00:1f.3 (XEN) [ 7.704944] PCI add device 0000:01:00.0 (XEN) [ 7.726878] PCI add device 0000:02:00.0 (XEN) [ 7.746884] PCI add device 0000:03:00.0 (XEN) [ 7.747319] PCI add device 0000:04:00.0 (XEN) [ 7.767088] PCI add device 0000:05:00.0 (XEN) [ 7.767513] PCI add device 0000:06:00.0 (XEN) [ 7.768234] PCI add device 0000:07:00.0 (XEN) [ 7.787118] PCI add device 0000:08:00.0 (XEN) [ 7.787441] PCI add device 0000:09:00.0 (XEN) [ 7.787915] PCI add device 0000:0a:08.0 (XEN) [ 7.788201] PCI add device 0000:0a:09.0 (XEN) [ 7.788486] PCI add device 0000:0a:0a.0 (XEN) [ 7.788767] PCI add device 0000:0a:0b.0 (XEN) [ 7.850118] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850138] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850183] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850202] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850209] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850226] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850273] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (XEN) [ 7.850293] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d080239753 (d1) [ 35.999994] HVM Loader (d1) [ 36.000293] Detected Xen v4.5.2 (d1) [ 36.000685] Xenbus rings @0xfeffc000, event channel 1 (d1) [ 36.001748] System requested SeaBIOS (d1) [ 36.001952] CPU speed is 2395 MHz (d1) [ 36.002577] Relocating guest memory for lowmem MMIO space disabled (XEN) [ 36.003796] irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (d1) [ 36.004196] PCI-ISA link 0 routed to IRQ5 (XEN) [ 36.004355] irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (d1) [ 36.004738] PCI-ISA link 1 routed to IRQ10 (XEN) [ 36.004885] irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (d1) [ 36.005268] PCI-ISA link 2 routed to IRQ11 (XEN) [ 36.005441] irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (d1) [ 36.005826] PCI-ISA link 3 routed to IRQ5 (d1) [ 36.021936] pci dev 01:3 INTA->IRQ10 (d1) [ 36.024582] pci dev 02:0 INTA->IRQ11 (d1) [ 36.030503] pci dev 04:0 INTA->IRQ5 (d1) [ 36.033877] pci dev 05:0 INTA->IRQ10 (d1) [ 36.037262] pci dev 06:0 INTA->IRQ11 (d1) [ 36.057653] No RAM in high memory; setting high_mem resource base to 100000000 (d1) [ 36.058139] pci dev 03:0 bar 10 size 002000000: 0f0000008 (d1) [ 36.059845] pci dev 02:0 bar 14 size 001000000: 0f2000008 (d1) [ 36.061531] pci dev 04:0 bar 10 size 000020000: 0f3000004 (XEN) [ 36.061685] memory_map:add: dom1 gfn=f3000 mfn=f7c00 nr=20 (d1) [ 36.064837] pci dev 03:0 bar 30 size 000010000: 0f3020000 (d1) [ 36.065415] pci dev 04:0 bar 30 size 000010000: 0f3030000 (d1) [ 36.066009] pci dev 05:0 bar 30 size 000010000: 0f3040000 (d1) [ 36.066606] pci dev 06:0 bar 10 size 000010000: 0f3050000 (XEN) [ 36.066787] memory_map:add: dom1 gfn=f3050 mfn=f7800 nr=10 (d1) [ 36.071651] pci dev 03:0 bar 14 size 000001000: 0f3060000 (XEN) [ 36.071944] memory_map:add: dom1 gfn=f3061 mfn=f7842 nr=1 (d1) [ 36.075268] pci dev 05:0 bar 14 size 000001000: 0f3061000 (d1) [ 36.075833] pci dev 02:0 bar 10 size 000000100: 00000c001 (d1) [ 36.077937] pci dev 05:0 bar 10 size 000000100: 00000c101 (XEN) [ 36.078289] ioport_map:add: dom1 gport=c100 mport=c200 nr=100 (d1) [ 36.081618] pci dev 01:1 bar 20 size 000000010: 00000c201 (d1) [ 36.083526] Multiprocessor initialisation: (d1) [ 36.106024] - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 36.125629] - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 36.125696] Testing HVM environment: (d1) [ 36.129259] - REP INSB across page boundaries ... passed (d1) [ 36.131211] - GS base MSRs and SWAPGS ... passed (d1) [ 36.131231] Passed 2 of 2 tests (d1) [ 36.131257] Writing SMBIOS tables ... (d1) [ 36.131983] Loading SeaBIOS ... (d1) [ 36.132018] Creating MP tables ... (d1) [ 36.132098] Loading ACPI ... (d1) [ 36.133403] vm86 TSS at fc00a380 (d1) [ 36.133666] BIOS map: (d1) [ 36.133693] 10000-100d3: Scratch space (d1) [ 36.133717] e0000-fffff: Main BIOS (d1) [ 36.133730] E820 table: (d1) [ 36.133777] [00]: 00000000:00000000 - 00000000:000a0000: RAM (d1) [ 36.133820] HOLE: 00000000:000a0000 - 00000000:000e0000 (d1) [ 36.133871] [01]: 00000000:000e0000 - 00000000:00100000: RESERVED (d1) [ 36.133921] [02]: 00000000:00100000 - 00000000:27800000: RAM (d1) [ 36.133964] HOLE: 00000000:27800000 - 00000000:fc000000 (d1) [ 36.134016] [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d1) [ 36.134228] Invoking SeaBIOS ... (XEN) [ 36.993929] Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) [ 36.993931] ************* VMCS Area ************** (XEN) [ 36.993933] *** Guest State *** (XEN) [ 36.993935] CR0: actual=0x0000000000000039, shadow=0x0000000000000011, gh_mask=ffffffffffffffff (XEN) [ 36.993937] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) [ 36.993938] CR3: actual=0x0000000000800000, target_count=0 (XEN) [ 36.993940] target0=0000000000000000, target1=0000000000000000 (XEN) [ 36.993941] target2=0000000000000000, target3=0000000000000000 (XEN) [ 36.993943] RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = 0x0000000100000000 (0x0000000100000000) (XEN) [ 36.993944] RFLAGS=0x0000000000000006 (0x0000000000000006) DR7 = 0x0000000000000400 (XEN) [ 36.993946] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) [ 36.993948] CS: sel=0x0008, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993950] DS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993952] SS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993953] ES: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993955] FS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993957] GS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 36.993958] GDTR: limit=0x00000037, base=0x00000000000f6d80 (XEN) [ 36.993960] LDTR: sel=0x0000, attr=0x00082, limit=0x00000000, base=0x0000000000000000 (XEN) [ 36.993961] IDTR: limit=0x00000000, base=0x00000000000f6dbe (XEN) [ 36.993963] TR: sel=0x0000, attr=0x0008b, limit=0x000000ff, base=0x0000000000000000 (XEN) [ 36.993965] Guest PAT = 0x0007040600070406 (XEN) [ 36.993966] TSC Offset = ffffffe521a87e2a (XEN) [ 36.993967] DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) [ 36.993969] Interruptibility=0000 ActivityState=0000 (XEN) [ 36.993970] *** Host State *** (XEN) [ 36.993971] RSP = 0xffff83080caa7f90 RIP = 0xffff82d0801f47a0 (XEN) [ 36.993973] CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) [ 36.993974] FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff83080caaec80 (XEN) [ 36.993976] GDTBase=ffff83080ca9f000 IDTBase=ffff83080caab000 (XEN) [ 36.993978] CR0=000000008005003b CR3=000000070bf71000 CR4=00000000000426f0 (XEN) [ 36.993980] Sysenter RSP=ffff83080caa7fc0 CS:RIP=e008:ffff82d080235550 (XEN) [ 36.993981] Host PAT = 0x0000050100070406 (XEN) [ 36.993982] *** Control State *** (XEN) [ 36.993983] PinBased=0000003f CPUBased=b6a065fe SecondaryExec=000000eb (XEN) [ 36.993985] EntryControls=000051ff ExitControls=000fefff (XEN) [ 36.993986] ExceptionBitmap=000600c2 (XEN) [ 36.993987] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.993989] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 36.993990] reason=80000021 qualification=00000000 (XEN) [ 36.993991] IDTVectoring: info=00000000 errcode=00000000 (XEN) [ 36.993992] TPR Threshold = 0x00 (XEN) [ 36.993994] EPT pointer = 0x000000070bf3f01e (XEN) [ 36.993995] Virtual processor ID = 0x0007 (XEN) [ 36.993996] ************************************** (XEN) [ 36.993997] domain_crash called from vmx.c:2505 (XEN) [ 36.993999] Domain 1 (vcpu#0) crashed on cpu#2: (XEN) [ 36.994001] ----[ Xen-4.5.2 x86_64 debug=n Not tainted ]---- (XEN) [ 36.994003] CPU: 2 (XEN) [ 36.994004] RIP: 0008:[<0000000100000000>] (XEN) [ 36.994005] RFLAGS: 0000000000000006 CONTEXT: hvm guest (d1v0) (XEN) [ 36.994008] rax: 0000000000000000 rbx: 0000000000000000 rcx: 00000000ffff1720 (XEN) [ 36.994009] rdx: 0000000000000059 rsi: 0000000000000059 rdi: 0000000000000000 (XEN) [ 36.994011] rbp: 0000000000000000 rsp: 0000000000006fdc r8: 0000000000000000 (XEN) [ 36.994012] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 36.994014] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 36.994015] r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) [ 36.994016] cr3: 0000000000800000 cr2: 0000000000000000 (XEN) [ 36.994018] ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 [-- Attachment #5: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-18 22:51 ` Atom2 @ 2015-11-18 23:17 ` Andrew Cooper 2015-11-19 0:31 ` Atom2 2015-11-19 10:24 ` Jan Beulich 0 siblings, 2 replies; 43+ messages in thread From: Andrew Cooper @ 2015-11-18 23:17 UTC (permalink / raw) To: Atom2, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel On 18/11/2015 22:51, Atom2 wrote: > Am 17.11.15 um 00:10 schrieb Atom2: >> Am 17.11.15 um 00:01 schrieb Andrew Cooper: >>> On 16/11/2015 19:16, Atom2 wrote: >>>> >>>> Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk: >>>>>>>> Your analysis was absolutely spot on. After re-thinking this for a >>>>>>>> moment, I thought going down that route first would make a lot of >>>>>>>> sense >>>>>>>> as PV guests still do work and one of the differences to HVM >>>>>>>> domUs is >>>>>>>> that the former do _not_ require SeaBIOS. Looking at my log >>>>>>>> files of >>>>>>>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to >>>>>>>> 1.8.2 in >>>>>>>> the relevant timeframe which obviously had not made it to the >>>>>>>> hvmloader >>>>>>>> of xen-4.5.1 as I did not re-compile xen after the upgrade of >>>>>>>> SeaBIOS. >>>>>>>> >>>>>>>> So I re-compiled xen-4.5.1 (obviously now using the installed >>>>>>>> SeaBIOS >>>>>>>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that >>>>>>>> seemed >>>>>>>> to strongly indicate that there indeed might be an issue with >>>>>>>> SeaBIOS as >>>>>>>> this probably was the only variable that had changed from the >>>>>>>> original >>>>>>>> install of xen-4.5.1. >>>>> I recall seeing this way back in Fedora 20 days. I narrowed it >>>>> down the >>>>> SeaBIOS version that was a standalone package to not have CONFIG_XEN. >>>>> >>>>> Having that fixed in the SeaBIOS package fixed it. >>>> Hi Konrad, Doug, Andrew (specifically added to this part of the >>>> thread)! >>>> Konrad, you might have found an interesting point. I did have a look >>>> at the ebuild for the failing version and in there I found the >>>> following comment: >>>> ====== comment from ebuild ======= >>>> # Upstream hasn't released a new binary. We snipe ours from >>>> Fedora for now. >>>> # >>>> http://code.coreboot.org/p/seabios/downloads/get/bios.bin-${PV}.gz >>>> ====== end comment from ebuild ======= >>>> which might in fact underline that there might be an issue similar to >>>> what you described above. >>>> >>>> What is also pretty interesting is the fact that the old (working) >>>> SeaBIOS version 1.7.5 installed as "bios.bin" under /usr/share/seabios >>>> is actually 262.144 bytes in size whereas the new (invalid) SeaBIOS >>>> 1.8.2 installed in the same location is only half as big: 131.072 >>>> bytes. >>>> >>>> I checked at the download site and the 1.8.2 binary version is indeed >>>> not available from http://code.coreboot.org/p/seabios/downloads/. But >>>> both the binary versions for 1.7.5 and 1.8.0 are available and both >>>> are acutually 262.144 bytes in size, so I'd be very surprised if the >>>> 1.8.2 version is really only half that size. By the way, the old >>>> working version (according to the ebuild) was directly downloaded from >>>> the above url and also shows an identical SHA1 digest to that version >>>> available for download there. >>>> >>>> To me this looks as if something is really wrong here. If anybody of >>>> you has access to a 1.8.2 version, could you please confirm whether >>>> there's really that big a size difference between the 1.7.5 and the >>>> 1.8.2 versions? Or is that difference probably attributable to the >>>> missing CONFIG_XEN option? >>>> >>>> Andrew: I havent't gotten around to run the debug version of the >>>> hypervisor again, but if the current suspicion turns out to be true, >>>> there's probably not much value in that anyways. Would you agree? >>> Sadly not. >> Fair enough. I'll try to get things done, hopefully somewhen tomorrow >> or, in case that doesn't work out, on Wednesday and will send you the >> requested information. >> >> Many thanks for your support, Atom2 >>> I accept that this issue is possibly fixed in newer SeaBIOS by working >>> around the issue. >>> >>> However, I stand by my original point. *There is no way the guest >>> should be able to get into this situation in the first place*, and its >>> implication of *there is a genuine hypervisor bug which we should track >>> down*, irrespective of whether the issue has been worked around elsehow > Hi Andrew, > as promised I have again tried with a debug build and the results are > very mixed. I initially tried to better understand what the debug USE > flag actually does in gentoo and my understanding (after reading the > so called ebuilds) is now that the XEN hypervisor will be built by > adding a gcc option of "debug=y" - and that's what should compile a > debug build - right? Yes indeed. > So I went on and again enabled the debug USE flag plus gdb symbols and > rebuilt the hypervisor in the hope that this created a valid and > working debug build. > > It, however, seems there's another problem lurking somewhere which > only manifests itself when I boot from the debug build of the hypervisor. You did manage to get at least one decent log from a properly debugbuild. However, all we need is the hvm_debug output. This patch: ---8<--- diff --git a/xen/include/asm-x86/hvm/support.h b/xen/include/asm-x86/hvm/support.h index 05ef5c5..7a8fbb5 100644 --- a/xen/include/asm-x86/hvm/support.h +++ b/xen/include/asm-x86/hvm/support.h @@ -28,7 +28,7 @@ #define HVM_DELIVER_NO_ERROR_CODE -1 -#ifndef NDEBUG +#if 1 #define DBG_LEVEL_0 (1 << 0) #define DBG_LEVEL_1 (1 << 1) #define DBG_LEVEL_2 (1 << 2) ---8<--- Will enable hvm_debug in a non-debug build of hypervisor. Can you try that please? > The system crashes early on with a DOUBLE FAULT in doIRQ - we have had > this already earlier in that thread. I am however a step further as > the disass in gdb now seems to provide not just an empty page full of > NULL values but rather something that might give you a hint why it > crashes that early on: Please see the attached disass file (doIRQ) > together with the serial console output (serial.dbg). The old NULL > value file was probably because I did not include gdb symbols in the > debug build at that time - my bad. The fact that it is completely consistent is useful from a debugging point of view. The disassembly of do_IRQ now looks like a plausible function, but the consistently faulting address has no plausible way of generating a double fault. I suspect therefore that something has caused memory corruption in Xen .text section. As an experiment, could you try booting with the minimum available command line options, which look to be just "com1=115200,8n1,0x3f8,4 console=com1,vga dom0_mem=4G,max:4G" to see whether it is an interaction of the options you have enabled. If the issue still reproduces, I will rework the previous debugging patch I gave you to definitely dump the actual code being run at the time of the fault. ~Andrew ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-18 23:17 ` Andrew Cooper @ 2015-11-19 0:31 ` Atom2 2015-11-19 1:06 ` Andrew Cooper 2015-11-19 10:24 ` Jan Beulich 1 sibling, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-19 0:31 UTC (permalink / raw) To: Andrew Cooper, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel [-- Attachment #1: Type: text/plain, Size: 3257 bytes --] Am 19.11.15 um 00:17 schrieb Andrew Cooper: > On 18/11/2015 22:51, Atom2 wrote: >> Am 17.11.15 um 00:10 schrieb Atom2: [big snip] >> Hi Andrew, >> as promised I have again tried with a debug build and the results are >> very mixed. I initially tried to better understand what the debug USE >> flag actually does in gentoo and my understanding (after reading the >> so called ebuilds) is now that the XEN hypervisor will be built by >> adding a gcc option of "debug=y" - and that's what should compile a >> debug build - right? > Yes indeed. > >> So I went on and again enabled the debug USE flag plus gdb symbols and >> rebuilt the hypervisor in the hope that this created a valid and >> working debug build. >> >> It, however, seems there's another problem lurking somewhere which >> only manifests itself when I boot from the debug build of the hypervisor. > You did manage to get at least one decent log from a properly debugbuild. > > However, all we need is the hvm_debug output. This patch: > > ---8<--- > diff --git a/xen/include/asm-x86/hvm/support.h > b/xen/include/asm-x86/hvm/support.h > index 05ef5c5..7a8fbb5 100644 > --- a/xen/include/asm-x86/hvm/support.h > +++ b/xen/include/asm-x86/hvm/support.h > @@ -28,7 +28,7 @@ > > #define HVM_DELIVER_NO_ERROR_CODE -1 > > -#ifndef NDEBUG > +#if 1 > #define DBG_LEVEL_0 (1 << 0) > #define DBG_LEVEL_1 (1 << 1) > #define DBG_LEVEL_2 (1 << 2) > ---8<--- > > Will enable hvm_debug in a non-debug build of hypervisor. Can you try > that please? Done. Please find the xl dmesg output attached to this mail. I guess this time it is really what you were expecting. Whether it does make sense though, might be a different issue. But I am confident in your abilities to figure out what's going on. >> The system crashes early on with a DOUBLE FAULT in doIRQ - we have had >> this already earlier in that thread. I am however a step further as >> the disass in gdb now seems to provide not just an empty page full of >> NULL values but rather something that might give you a hint why it >> crashes that early on: Please see the attached disass file (doIRQ) >> together with the serial console output (serial.dbg). The old NULL >> value file was probably because I did not include gdb symbols in the >> debug build at that time - my bad. > The fact that it is completely consistent is useful from a debugging > point of view. > > The disassembly of do_IRQ now looks like a plausible function, but the > consistently faulting address has no plausible way of generating a > double fault. I suspect therefore that something has caused memory > corruption in Xen .text section. > > As an experiment, could you try booting with the minimum available > command line options, which look to be just "com1=115200,8n1,0x3f8,4 > console=com1,vga dom0_mem=4G,max:4G" to see whether it is an interaction > of the options you have enabled. I haven't done that yet as this will again require a re-compile of the non-working debug build. I'll probably give that a try tomorrow. > If the issue still reproduces, I will rework the previous debugging > patch I gave you to definitely dump the actual code being run at the > time of the fault. > > ~Andrew Thanks Atom2 [-- Attachment #2: xl.dmesg.dbg --] [-- Type: text/plain, Size: 56193 bytes --] Xen 4.5.2 (XEN) [ 0.000000] Xen version 4.5.2 (@herrenhauspark.com) (x86_64-pc-linux-gnu-gcc (Gentoo Hardened 4.9.3 p1.2, pie-0.6.3) 4.9.3) debug=n Thu Nov 19 00:54:45 CET 2015 (XEN) [ 0.000000] Latest ChangeSet: (XEN) [ 0.000000] Bootloader: GRUB 2.00 (XEN) [ 0.000000] Command line: placeholder ucode=-1 loglvl=all guest_loglvl=all hvm_debug=0xc3f console_timestamps=boot dom0_mem=4G,max:4G tmem=1 tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tslice_ms=5 bootscrub=0 (XEN) [ 0.000000] Video information: (XEN) [ 0.000000] VGA is text mode 80x25, font 8x16 (XEN) [ 0.000000] VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) [ 0.000000] Disc information: (XEN) [ 0.000000] Found 2 MBR signatures (XEN) [ 0.000000] Found 2 EDD information structures (XEN) [ 0.000000] Xen-e820 RAM map: (XEN) [ 0.000000] 0000000000000000 - 000000000009d800 (usable) (XEN) [ 0.000000] 000000000009d800 - 00000000000a0000 (reserved) (XEN) [ 0.000000] 00000000000e0000 - 0000000000100000 (reserved) (XEN) [ 0.000000] 0000000000100000 - 0000000020000000 (usable) (XEN) [ 0.000000] 0000000020000000 - 0000000020200000 (reserved) (XEN) [ 0.000000] 0000000020200000 - 0000000040000000 (usable) (XEN) [ 0.000000] 0000000040000000 - 0000000040200000 (reserved) (XEN) [ 0.000000] 0000000040200000 - 00000000db9f0000 (usable) (XEN) [ 0.000000] 00000000db9f0000 - 00000000dc0da000 (reserved) (XEN) [ 0.000000] 00000000dc0da000 - 00000000dc1f9000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc1f9000 - 00000000dc651000 (reserved) (XEN) [ 0.000000] 00000000dc651000 - 00000000dc652000 (usable) (XEN) [ 0.000000] 00000000dc652000 - 00000000dc695000 (ACPI NVS) (XEN) [ 0.000000] 00000000dc695000 - 00000000dcdba000 (usable) (XEN) [ 0.000000] 00000000dcdba000 - 00000000dcff2000 (reserved) (XEN) [ 0.000000] 00000000dcff2000 - 00000000dd000000 (usable) (XEN) [ 0.000000] 00000000dd800000 - 00000000dfa00000 (reserved) (XEN) [ 0.000000] 00000000f8000000 - 00000000fc000000 (reserved) (XEN) [ 0.000000] 00000000fec00000 - 00000000fec01000 (reserved) (XEN) [ 0.000000] 00000000fed00000 - 00000000fed04000 (reserved) (XEN) [ 0.000000] 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) [ 0.000000] 00000000fee00000 - 00000000fee01000 (reserved) (XEN) [ 0.000000] 00000000ff000000 - 0000000100000000 (reserved) (XEN) [ 0.000000] 0000000100000000 - 000000081e600000 (usable) (XEN) [ 0.000000] ACPI: RSDP 000F0490, 0024 (r2 ALASKA) (XEN) [ 0.000000] ACPI: XSDT DC1E9078, 0074 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FACP DC1F3710, 00F4 (r4 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: DSDT DC1E9188, A587 (r2 ALASKA A M I 1 INTL 20051117) (XEN) [ 0.000000] ACPI: FACS DC1F7F80, 0040 (XEN) [ 0.000000] ACPI: APIC DC1F3808, 0092 (r3 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: FPDT DC1F38A0, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) [ 0.000000] ACPI: MCFG DC1F38E8, 003C (r1 ALASKA A M I 1072009 MSFT 97) (XEN) [ 0.000000] ACPI: HPET DC1F3928, 0038 (r1 ALASKA A M I 1072009 AMI. 5) (XEN) [ 0.000000] ACPI: SSDT DC1F3960, 036D (r1 SataRe SataTabl 1000 INTL 20091112) (XEN) [ 0.000000] ACPI: SSDT DC1F3CD0, 081E (r1 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: SSDT DC1F44F0, 0A92 (r1 PmRef CpuPm 3000 INTL 20051117) (XEN) [ 0.000000] ACPI: DMAR DC1F4F88, 00B0 (r1 INTEL SNB 1 INTL 1) (XEN) [ 0.000000] ACPI: ASF! DC1F5038, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) [ 0.000000] System RAM: 32674MB (33458948kB) (XEN) [ 0.000000] No NUMA configuration found (XEN) [ 0.000000] Faking a node at 0000000000000000-000000081e600000 (XEN) [ 0.000000] Domain heap initialised (XEN) [ 0.000000] found SMP MP-table at 000fd8d0 (XEN) [ 0.000000] DMI 2.7 present. (XEN) [ 0.000000] Using APIC driver default (XEN) [ 0.000000] ACPI: PM-Timer IO Port: 0x408 (XEN) [ 0.000000] ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) [ 0.000000] ACPI: 32/64X FACS address mismatch in FADT - dc1f7f80/0000000000000000, using 32 (XEN) [ 0.000000] ACPI: wakeup_vec[dc1f7f8c], vec_size[20] (XEN) [ 0.000000] ACPI: Local APIC address 0xfee00000 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) [ 0.000000] Processor #0 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) [ 0.000000] Processor #2 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) [ 0.000000] Processor #4 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) [ 0.000000] Processor #6 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) (XEN) [ 0.000000] Processor #1 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) (XEN) [ 0.000000] Processor #3 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) (XEN) [ 0.000000] Processor #5 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) (XEN) [ 0.000000] Processor #7 6:10 APIC version 21 (XEN) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) [ 0.000000] ACPI: IRQ0 used by override. (XEN) [ 0.000000] ACPI: IRQ2 used by override. (XEN) [ 0.000000] ACPI: IRQ9 used by override. (XEN) [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) [ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [ 0.000000] ERST table was not found (XEN) [ 0.000000] Using ACPI (MADT) for SMP configuration information (XEN) [ 0.000000] SMP: Allowing 8 CPUs (0 hotplug CPUs) (XEN) [ 0.000000] IRQ limits: 24 GSI, 1528 MSI/MSI-X (XEN) [ 0.000000] Switched to APIC driver x2apic_cluster. (XEN) [ 0.000000] Using scheduler: SMP Credit Scheduler (credit) (XEN) [ 0.875010] Detected 2394.655 MHz processor. (XEN) [ 0.877796] Initing memory sharing. (XEN) [ 0.878310] xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) [ 0.878835] mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) [ 0.879866] Intel machine check reporting enabled (XEN) [ 0.880385] alt table ffff82d0802d1a90 -> ffff82d0802d2bd0 (XEN) [ 0.881135] PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f (XEN) [ 0.882146] PCI: MCFG area at f8000000 reserved in E820 (XEN) [ 0.882665] PCI: Using MCFG for segment 0000 bus 00-3f (XEN) [ 0.883609] Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) [ 0.884130] Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) [ 0.884647] Intel VT-d Snoop Control not enabled. (XEN) [ 0.885166] Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) [ 0.885683] Intel VT-d Queued Invalidation enabled. (XEN) [ 0.886197] Intel VT-d Interrupt Remapping enabled. (XEN) [ 0.886711] Intel VT-d Shared EPT tables not enabled. (XEN) [ 0.895408] I/O virtualisation enabled (XEN) [ 0.895915] - Dom0 mode: Relaxed (XEN) [ 0.896419] Interrupt remapping enabled (XEN) [ 0.897155] Enabled directed EOI with ioapic_ack_old on! (XEN) [ 0.897961] ENABLING IO-APIC IRQs (XEN) [ 0.898466] -> Using old ACK method (XEN) [ 0.899281] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 1.105002] TSC deadline timer enabled (XEN) [ 1.712306] Platform timer is 14.318MHz HPET (XEN) [ 1.712831] Allocated console ring of 64 KiB. (XEN) [ 1.713952] microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 1.714965] mwait-idle: MWAIT substates: 0x1120 (XEN) [ 1.715478] mwait-idle: v0.4 model 0x2a (XEN) [ 1.715986] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [ 1.716512] VMX: Supported advanced features: (XEN) [ 1.717023] - APIC MMIO access virtualisation (XEN) [ 1.717532] - APIC TPR shadow (XEN) [ 1.718035] - Extended Page Tables (EPT) (XEN) [ 1.718544] - Virtual-Processor Identifiers (VPID) (XEN) [ 1.719057] - Virtual NMI (XEN) [ 1.719559] - MSR direct-access bitmap (XEN) [ 1.720067] - Unrestricted Guest (XEN) [ 1.720575] HVM: ASIDs enabled. (XEN) [ 1.721080] HVM: VMX enabled (XEN) [ 1.721582] HVM: Hardware Assisted Paging (HAP) detected (XEN) [ 1.722100] HVM: HAP page sizes: 4kB, 2MB (XEN) [ 1.723221] microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 1.724258] Brought up 8 CPUs (XEN) [ 1.724766] microcode: CPU4 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 1.731583] tmem: initialized comp=1 dedup=1 tze=0 (XEN) [ 1.732100] microcode: CPU7 updated from revision 0x28 to 0x29, date = 2013-06-12 (XEN) [ 1.753207] ACPI sleep modes: S3 (XEN) [ 1.753711] mcheck_poll: Machine check polling timer started. (XEN) [ 1.754237] Dom0 has maximum 792 PIRQs (XEN) [ 1.754787] *** LOADING DOMAIN 0 *** (XEN) [ 1.933380] Xen kernel: 64-bit, lsb, compat32 (XEN) [ 1.933894] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c00000 (XEN) [ 1.935348] PHYSICAL MEMORY ARRANGEMENT: (XEN) [ 1.935857] Dom0 alloc.: 0000000800000000->0000000804000000 (1029890 pages to be allocated) (XEN) [ 1.936878] Init. ramdisk: 000000081dcff000->000000081e5fc600 (XEN) [ 1.937403] VIRTUAL MEMORY ARRANGEMENT: (XEN) [ 1.937911] Loaded kernel: ffffffff81000000->ffffffff81c00000 (XEN) [ 1.938432] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [ 1.938951] Phys-Mach map: ffffffff81c00000->ffffffff82400000 (XEN) [ 1.939472] Start info: ffffffff82400000->ffffffff824004b4 (XEN) [ 1.939991] Page tables: ffffffff82401000->ffffffff82418000 (XEN) [ 1.940512] Boot stack: ffffffff82418000->ffffffff82419000 (XEN) [ 1.941032] TOTAL: ffffffff80000000->ffffffff82800000 (XEN) [ 1.941552] ENTRY ADDRESS: ffffffff818e31f0 (XEN) [ 1.942866] Dom0 has maximum 8 VCPUs (XEN) [ 5.106001] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 5.114635] Std. Loglevel: All (XEN) [ 5.115139] Guest Loglevel: All (XEN) [ 5.115643] Xen is relinquishing VGA console. (XEN) [ 5.116683] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) [ 5.116719] Freed 308kB init memory. (XEN) [ 5.366129] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.366133] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff81646d10. (XEN) [ 5.366135] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff81648e70. (XEN) [ 5.366138] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.366140] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000. (XEN) [ 5.366142] traps.c:2590:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.366144] traps.c:2590:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.460630] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.460635] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff83080cab3000 to 0xffffffff81646d10. (XEN) [ 5.460639] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000083 from 0xffff83080cab3080 to 0xffffffff81648e70. (XEN) [ 5.460642] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.460645] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000175 from 0xffff83080cab7fc0 to 0x0000000000000000. (XEN) [ 5.460648] traps.c:2590:d0v1 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.460652] traps.c:2590:d0v1 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.461026] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.461029] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000082 from 0xffff83080caab000 to 0xffffffff81646d10. (XEN) [ 5.461032] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000083 from 0xffff83080caab080 to 0xffffffff81648e70. (XEN) [ 5.461034] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.461036] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000175 from 0xffff83080caaffc0 to 0x0000000000000000. (XEN) [ 5.461039] traps.c:2590:d0v2 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.461041] traps.c:2590:d0v2 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.461361] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.461364] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca93000 to 0xffffffff81646d10. (XEN) [ 5.461366] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca93080 to 0xffffffff81648e70. (XEN) [ 5.461368] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.461370] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca97fc0 to 0x0000000000000000. (XEN) [ 5.461373] traps.c:2590:d0v3 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.461375] traps.c:2590:d0v3 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.461663] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.461666] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000082 from 0xffff83080ca8b000 to 0xffffffff81646d10. (XEN) [ 5.461669] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000083 from 0xffff83080ca8b080 to 0xffffffff81648e70. (XEN) [ 5.461671] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.461673] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000175 from 0xffff83080ca8ffc0 to 0x0000000000000000. (XEN) [ 5.461676] traps.c:2590:d0v4 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.461678] traps.c:2590:d0v4 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.461949] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.461952] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063fb000 to 0xffffffff81646d10. (XEN) [ 5.461954] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063fb080 to 0xffffffff81648e70. (XEN) [ 5.461956] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.461958] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000175 from 0xffff8308063fffc0 to 0x0000000000000000. (XEN) [ 5.461961] traps.c:2590:d0v5 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.461963] traps.c:2590:d0v5 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.462228] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.462232] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063eb000 to 0xffffffff81646d10. (XEN) [ 5.462234] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063eb080 to 0xffffffff81648e70. (XEN) [ 5.462236] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.462239] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000175 from 0xffff8308063effc0 to 0x0000000000000000. (XEN) [ 5.462241] traps.c:2590:d0v6 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.462243] traps.c:2590:d0v6 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 5.462510] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) [ 5.462513] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000082 from 0xffff8308063db000 to 0xffffffff81646d10. (XEN) [ 5.462515] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000083 from 0xffff8308063db080 to 0xffffffff81648e70. (XEN) [ 5.462517] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) [ 5.462519] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000175 from 0xffff8308063dffc0 to 0x0000000000000000. (XEN) [ 5.462522] traps.c:2590:d0v7 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237550 to 0xffffffff81648cf0. (XEN) [ 5.462524] traps.c:2590:d0v7 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) [ 6.611987] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [ 6.611990] PCI add device 0000:00:00.0 (XEN) [ 6.612216] PCI add device 0000:00:01.0 (XEN) [ 6.612434] PCI add device 0000:00:01.1 (XEN) [ 6.612652] PCI add device 0000:00:02.0 (XEN) [ 6.612878] PCI add device 0000:00:06.0 (XEN) [ 6.613162] PCI add device 0000:00:16.0 (XEN) [ 6.613481] PCI add device 0000:00:19.0 (XEN) [ 6.613812] PCI add device 0000:00:1a.0 (XEN) [ 6.614112] PCI add device 0000:00:1b.0 (XEN) [ 6.614480] PCI add device 0000:00:1c.0 (XEN) [ 6.614855] PCI add device 0000:00:1c.4 (XEN) [ 6.615220] PCI add device 0000:00:1c.6 (XEN) [ 6.615553] PCI add device 0000:00:1d.0 (XEN) [ 6.615764] PCI add device 0000:00:1e.0 (XEN) [ 6.616014] PCI add device 0000:00:1f.0 (XEN) [ 6.616291] PCI add device 0000:00:1f.2 (XEN) [ 6.616473] PCI add device 0000:00:1f.3 (XEN) [ 6.616743] PCI add device 0000:01:00.0 (XEN) [ 6.631514] PCI add device 0000:02:00.0 (XEN) [ 6.651593] PCI add device 0000:03:00.0 (XEN) [ 6.652040] PCI add device 0000:04:00.0 (XEN) [ 6.671872] PCI add device 0000:05:00.0 (XEN) [ 6.672389] PCI add device 0000:06:00.0 (XEN) [ 6.673158] PCI add device 0000:07:00.0 (XEN) [ 6.691995] PCI add device 0000:08:00.0 (XEN) [ 6.692326] PCI add device 0000:09:00.0 (XEN) [ 6.692835] PCI add device 0000:0a:08.0 (XEN) [ 6.693120] PCI add device 0000:0a:09.0 (XEN) [ 6.693403] PCI add device 0000:0a:0a.0 (XEN) [ 6.693682] PCI add device 0000:0a:0b.0 (XEN) [ 6.767732] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767751] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767796] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767812] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767819] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767836] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767884] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 6.767901] traps.c:3162: GPF (0000): ffff82d08019917c -> ffff82d08023b74d (XEN) [ 32.801381] [HVM:0.1] <do_hvm_op> set param 4 = 1 (XEN) [ 32.801388] [HVM:0.1] <do_hvm_op> set param 11 = 1 (XEN) [ 32.801392] [HVM:0.1] <do_hvm_op> set param 10 = 1 (XEN) [ 32.801397] [HVM:0.1] <do_hvm_op> set param 16 = 1 (XEN) [ 32.801402] [HVM:0.1] <do_hvm_op> set param 24 = 0 (XEN) [ 32.885059] [HVM:0.2] <do_hvm_op> set param 1 = feffc (XEN) [ 32.885062] [HVM:0.2] <do_hvm_op> set param 6 = feffb (XEN) [ 32.885065] [HVM:0.2] <do_hvm_op> set param 5 = feffd (XEN) [ 32.885067] [HVM:0.2] <do_hvm_op> set param 17 = fefff (XEN) [ 32.885069] [HVM:0.2] <do_hvm_op> set param 27 = feff8 (XEN) [ 32.885071] [HVM:0.2] <do_hvm_op> set param 28 = feff9 (XEN) [ 32.885073] [HVM:0.2] <do_hvm_op> set param 29 = feffa (XEN) [ 32.885105] [HVM:0.2] <do_hvm_op> set param 32 = feff0 (XEN) [ 32.885108] [HVM:0.2] <do_hvm_op> set param 33 = 8 (XEN) [ 32.885127] [HVM:0.2] <do_hvm_op> set param 12 = feffe000 (XEN) [ 32.885546] [HVM:0.2] <do_hvm_op> get param 1 = feffc (XEN) [ 32.885549] [HVM:0.2] <do_hvm_op> get param 17 = fefff (XEN) [ 32.885551] [HVM:0.2] <do_hvm_op> set param 2 = 1 (XEN) [ 32.885554] [HVM:0.2] <do_hvm_op> set param 18 = 2 (XEN) [ 32.885838] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885848] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885860] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885868] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885878] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885891] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885896] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885900] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885904] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885907] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885912] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885916] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885921] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885925] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885930] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885933] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885938] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885942] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885947] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885951] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885955] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885958] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885962] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885965] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885969] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885973] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885977] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885980] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885984] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885987] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.885993] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.885996] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886000] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886004] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886007] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886011] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886022] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886025] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886031] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886034] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886039] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886043] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886047] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886050] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886054] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886057] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886061] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886065] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886068] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886072] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886076] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886079] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886083] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886087] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886090] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886094] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886098] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886101] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886105] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886109] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886112] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886116] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886120] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886123] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886127] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886131] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886134] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886138] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886142] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886145] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886149] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886152] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886156] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886160] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886164] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886167] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886171] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886174] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886178] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886182] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886186] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886189] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886193] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886196] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886200] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886204] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886207] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886211] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886215] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886218] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886222] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886226] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886229] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886233] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886237] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886240] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886244] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886247] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886251] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886255] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886258] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886262] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886266] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886269] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886273] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886277] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886280] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886284] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886288] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886291] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886295] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886298] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886302] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886306] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886309] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886313] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886317] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886320] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886324] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886328] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886331] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886335] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886339] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886342] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886346] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886349] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886353] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886357] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886360] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886364] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886368] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886371] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886375] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886379] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886382] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886386] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886390] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886393] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886397] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886400] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886404] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886408] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886411] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886415] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886419] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886422] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886426] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886430] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886433] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886437] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886441] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886444] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886448] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886451] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886455] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886459] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886463] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886466] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886470] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886473] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886477] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886481] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886484] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886488] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886493] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886497] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886502] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886506] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886511] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886515] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886520] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886524] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886529] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886532] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886536] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886540] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886545] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886548] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 32.886553] [HVM:0.2] <do_hvm_op> get param 4 = 1 (XEN) [ 32.886557] [HVM:0.2] <do_hvm_op> get param 24 = 0 (XEN) [ 33.597994] [HVM:0.4] <do_hvm_op> get param 5 = feffd (XEN) [ 33.598028] [HVM:0.4] <do_hvm_op> get param 6 = feffb (XEN) [ 33.598110] [HVM:0.4] <do_hvm_op> get param 26 = 4 (XEN) [ 34.504382] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.505934] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.506207] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.507894] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.508004] HVM Loader (XEN) [ 34.508093] [HVM:1.0] <vmx_msr_write_intercept> ecx=0x40000000, msr_value=0x80000 (XEN) [ 34.508096] [HVM:1.0] <long_mode_do_msr_write> msr 0x40000000 content 0x80000 (XEN) [ 34.508116] [HVM:1.0] <hvm_do_hypercall> hcall17(1, 19c690, 19c690, 1, 19c67c, 19c6b8) (XEN) [ 34.508121] [HVM:1.0] <hvm_do_hypercall> hcall17 -> 0 (d1) [ 34.508308] Detected Xen v4.5.2 (XEN) [ 34.508322] [HVM:1.0] <hvm_do_hypercall> hcall34(1, 19c5f0, e9, 1, 19c67c, 19c608) (XEN) [ 34.508326] [HVM:1.0] <do_hvm_op> get param 1 = feffc (XEN) [ 34.508327] [HVM:1.0] <hvm_do_hypercall> hcall34 -> 0 (XEN) [ 34.508338] [HVM:1.0] <hvm_do_hypercall> hcall34(1, 19c5f0, 19c628, 1, 19c67c, 19c608) (XEN) [ 34.508341] [HVM:1.0] <do_hvm_op> get param 2 = 1 (XEN) [ 34.508342] [HVM:1.0] <hvm_do_hypercall> hcall34 -> 0 (d1) [ 34.508707] Xenbus rings @0xfeffc000, event channel 1 (XEN) [ 34.508805] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c5ac, 1, 2, f, 19c5f8) (XEN) [ 34.508809] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.508832] [HVM:1.0] <hvm_do_hypercall> hcall12(7, 19c540, fdfff000, 0, 19c67c, 19c558) (XEN) [ 34.508851] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 0 (d1) [ 34.509105] System requested SeaBIOS (d1) [ 34.509307] CPU speed is 2395 MHz (XEN) [ 34.509460] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4bc, 1, 2, 20, 19c508) (XEN) [ 34.509464] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.509524] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c480, fdfff800, 803a0, 19c67c, 19c498) (XEN) [ 34.509527] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.509564] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.510010] Relocating guest memory for lowmem MMIO space disabled (XEN) [ 34.510107] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4bc, 1, 2, 18, 19c508) (XEN) [ 34.510111] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.510147] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c480, fdfff800, 803a0, 19c67c, 19c498) (XEN) [ 34.510150] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.510399] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.510433] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c480, fdfff800, 803a0, 19c67c, 19c498) (XEN) [ 34.510436] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.510696] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.510751] irq.c:270: Dom1 PCI link 0 changed 0 -> 5 (XEN) [ 34.510827] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.511078] PCI-ISA link 0 routed to IRQ5 (XEN) [ 34.511199] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.511237] irq.c:270: Dom1 PCI link 1 changed 0 -> 10 (d1) [ 34.511587] PCI-ISA link 1 routed to IRQ10 (XEN) [ 34.511730] irq.c:270: Dom1 PCI link 2 changed 0 -> 11 (XEN) [ 34.511961] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.512075] PCI-ISA link 2 routed to IRQ11 (XEN) [ 34.512208] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.512259] irq.c:270: Dom1 PCI link 3 changed 0 -> 5 (d1) [ 34.512595] PCI-ISA link 3 routed to IRQ5 (XEN) [ 34.512743] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.512853] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.512935] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.513001] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.513114] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.513192] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.514425] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.514587] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.516800] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.516860] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.516941] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.517001] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.531521] pci dev 01:3 INTA->IRQ10 (d1) [ 34.536813] pci dev 02:0 INTA->IRQ11 (d1) [ 34.546361] pci dev 04:0 INTA->IRQ5 (d1) [ 34.551110] pci dev 05:0 INTA->IRQ10 (XEN) [ 34.553102] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.555727] pci dev 06:0 INTA->IRQ11 (XEN) [ 34.583097] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (d1) [ 34.584700] No RAM in high memory; setting high_mem resource base to 100000000 (d1) [ 34.585267] pci dev 03:0 bar 10 size 002000000: 0f0000008 (d1) [ 34.587398] pci dev 02:0 bar 14 size 001000000: 0f2000008 (d1) [ 34.589320] pci dev 04:0 bar 10 size 000020000: 0f3000004 (XEN) [ 34.589517] memory_map:add: dom1 gfn=f3000 mfn=f7c00 nr=20 (d1) [ 34.593122] pci dev 03:0 bar 30 size 000010000: 0f3020000 (d1) [ 34.593737] pci dev 04:0 bar 30 size 000010000: 0f3030000 (d1) [ 34.594372] pci dev 05:0 bar 30 size 000010000: 0f3040000 (d1) [ 34.595004] pci dev 06:0 bar 10 size 000010000: 0f3050000 (XEN) [ 34.595202] memory_map:add: dom1 gfn=f3050 mfn=f7800 nr=10 (d1) [ 34.600185] pci dev 03:0 bar 14 size 000001000: 0f3060000 (XEN) [ 34.600512] memory_map:add: dom1 gfn=f3061 mfn=f7842 nr=1 (d1) [ 34.603811] pci dev 05:0 bar 14 size 000001000: 0f3061000 (d1) [ 34.604435] pci dev 02:0 bar 10 size 000000100: 00000c001 (d1) [ 34.606840] pci dev 05:0 bar 10 size 000000100: 00000c101 (XEN) [ 34.607280] ioport_map:add: dom1 gport=c100 mport=c200 nr=100 (d1) [ 34.610787] pci dev 01:1 bar 20 size 000000010: 00000c201 (d1) [ 34.612870] Multiprocessor initialisation: (d1) [ 34.637565] - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (XEN) [ 34.637648] [HVM:1.1] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.637660] [HVM:1.1] <hvm_set_cr0> Update CR0 value = 11 (d1) [ 34.654138] - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d1) [ 34.654198] Testing HVM environment: (XEN) [ 34.656118] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 80000011 (XEN) [ 34.656120] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 80000011 (XEN) [ 34.656646] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 11 (XEN) [ 34.656647] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 11 (d1) [ 34.657630] - REP INSB across page boundaries ... passed (XEN) [ 34.659566] [HVM:1.0] <hvm_mov_to_cr> CR4, value = 20 (XEN) [ 34.659573] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 80000011 (XEN) [ 34.659574] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 80000011 (XEN) [ 34.659575] [HVM:1.0] <hvm_set_cr0> Enabling long mode (XEN) [ 34.659578] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 11 (XEN) [ 34.659579] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 11 (XEN) [ 34.659583] [HVM:1.0] <hvm_mov_to_cr> CR4, value = 0 (d1) [ 34.659592] - GS base MSRs and SWAPGS ... passed (d1) [ 34.659612] Passed 2 of 2 tests (d1) [ 34.659637] Writing SMBIOS tables ... (XEN) [ 34.659641] [HVM:1.0] <hvm_do_hypercall> hcall17(8, 19c5f0, 80220, 152240, 19c67c, 19c618) (XEN) [ 34.659643] [HVM:1.0] <hvm_do_hypercall> hcall17 -> 0 (XEN) [ 34.659645] [HVM:1.0] <hvm_do_hypercall> hcall17(0, 0, 80220, 152240, 19c67c, 19c618) (XEN) [ 34.659646] [HVM:1.0] <hvm_do_hypercall> hcall17 -> 40005 (XEN) [ 34.659649] [HVM:1.0] <hvm_do_hypercall> hcall17(1, 19c5e0, 80220, 40005, 4, 19c618) (XEN) [ 34.659650] [HVM:1.0] <hvm_do_hypercall> hcall17 -> 0 (XEN) [ 34.659655] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 19, 19c468) (XEN) [ 34.659657] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.659664] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659667] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659693] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659695] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659756] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 19, 19c468) (XEN) [ 34.659758] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.659761] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659763] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659776] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659777] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659817] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 1a, 19c468) (XEN) [ 34.659819] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.659822] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659824] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659837] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 4, 19c3f8) (XEN) [ 34.659839] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659877] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 21, 19c468) (XEN) [ 34.659880] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.659883] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 1002e, 19c3f8) (XEN) [ 34.659885] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659899] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 1002e, 19c3f8) (XEN) [ 34.659901] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659940] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 21, 19c468) (XEN) [ 34.659942] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.659945] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107052, 19c3f8) (XEN) [ 34.659947] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659960] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107052, 19c3f8) (XEN) [ 34.659961] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.659999] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 1c, 19c468) (XEN) [ 34.660002] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660006] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107094, 19c3f8) (XEN) [ 34.660007] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660019] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107094, 19c3f8) (XEN) [ 34.660021] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660059] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 22, 19c468) (XEN) [ 34.660062] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660065] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 19c530, 19c3f8) (XEN) [ 34.660066] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660081] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 19c530, 19c3f8) (XEN) [ 34.660083] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660121] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 24, 19c468) (XEN) [ 34.660124] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660127] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 100b0, 19c3f8) (XEN) [ 34.660129] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660144] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 100b0, 19c3f8) (XEN) [ 34.660145] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660184] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 25, 19c468) (XEN) [ 34.660187] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660190] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107052, 19c3f8) (XEN) [ 34.660191] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660206] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 107052, 19c3f8) (XEN) [ 34.660208] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660248] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 13, 19c468) (XEN) [ 34.660250] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660253] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 10115, 19c3f8) (XEN) [ 34.660255] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660270] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 10115, 19c3f8) (XEN) [ 34.660272] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660310] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c41c, 1, 2, 21, 19c468) (XEN) [ 34.660313] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660316] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 54, 19c3f8) (XEN) [ 34.660318] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660332] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c3e0, fdfff800, 803a0, 54, 19c3f8) (XEN) [ 34.660334] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660372] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c44c, fc000, 1, fc001152, 19c478) (XEN) [ 34.660389] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (d1) [ 34.660413] Loading SeaBIOS ... (d1) [ 34.660452] Creating MP tables ... (XEN) [ 34.660481] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c5ac, 1, 2, e, 19c5f8) (XEN) [ 34.660484] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.660487] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c570, fdfff800, 803a0, 9f800, 19c588) (XEN) [ 34.660488] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.660503] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c570, fdfff800, 803a0, 9f800, 19c588) (XEN) [ 34.660505] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (d1) [ 34.660542] Loading ACPI ... (XEN) [ 34.660545] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c52c, 100d3, 1, 9f800, 19c558) (XEN) [ 34.660549] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660554] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc001, 1, fc009990, 19c528) (XEN) [ 34.660557] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660560] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc002, 1, fc009990, 19c528) (XEN) [ 34.660563] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660565] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc003, 1, fc009990, 19c528) (XEN) [ 34.660568] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660571] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc004, 1, fc009990, 19c528) (XEN) [ 34.660574] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660576] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc005, 1, fc009990, 19c528) (XEN) [ 34.660579] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660581] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc006, 1, fc009990, 19c528) (XEN) [ 34.660584] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660586] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc007, 1, fc009990, 19c528) (XEN) [ 34.660589] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.660591] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc008, 1, fc009990, 19c528) (XEN) [ 34.660594] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.661187] [HVM:1.0] <hvm_do_hypercall> hcall12(6, 19c4fc, fc009, 1, fc00a037, 19c528) (XEN) [ 34.661191] [HVM:1.0] <hvm_do_hypercall> hcall12 -> 1 (XEN) [ 34.661234] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4cc, 1, 2, 11, 19c518) (XEN) [ 34.661236] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.661239] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661241] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661255] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661257] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661281] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4cc, 1, 2, 11, 19c518) (XEN) [ 34.661284] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.661287] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661288] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661302] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661304] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661359] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4cc, 1, 2, 17, 19c518) (XEN) [ 34.661361] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.661365] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661366] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661381] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, 8, 19c4a8) (XEN) [ 34.661382] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661438] [HVM:1.0] <hvm_do_hypercall> hcall32(4, 19c4cc, 1, 2, 17, 19c518) (XEN) [ 34.661440] [HVM:1.0] <hvm_do_hypercall> hcall32 -> 0 (XEN) [ 34.661444] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, fc00a0f0, 19c4a8) (XEN) [ 34.661445] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661460] [HVM:1.0] <hvm_do_hypercall> hcall29(3, 19c490, fdfff800, 803a0, fc00a0f0, 19c4a8) (XEN) [ 34.661462] [HVM:1.0] <hvm_do_hypercall> hcall29 -> 0 (XEN) [ 34.661855] [HVM:1.0] <hvm_do_hypercall> hcall34(0, 19c624, 0, 152240, 9f800, 19c638) (XEN) [ 34.661858] [HVM:1.0] <do_hvm_op> set param 19 = 1 (XEN) [ 34.661858] [HVM:1.0] <hvm_do_hypercall> hcall34 -> 0 (XEN) [ 34.661867] [HVM:1.0] <hvm_do_hypercall> hcall34(0, 19c624, 0, 152240, 9f800, 19c638) (XEN) [ 34.661868] [HVM:1.0] <do_hvm_op> set param 15 = fc00a380 (XEN) [ 34.661869] [HVM:1.0] <hvm_do_hypercall> hcall34 -> 0 (d1) [ 34.661890] vm86 TSS at fc00a380 (d1) [ 34.662226] BIOS map: (d1) [ 34.662261] 10000-100d3: Scratch space (d1) [ 34.662282] e0000-fffff: Main BIOS (d1) [ 34.662293] E820 table: (d1) [ 34.662335] [00]: 00000000:00000000 - 00000000:000a0000: RAM (d1) [ 34.662373] HOLE: 00000000:000a0000 - 00000000:000e0000 (d1) [ 34.662419] [01]: 00000000:000e0000 - 00000000:00100000: RESERVED (d1) [ 34.662461] [02]: 00000000:00100000 - 00000000:27800000: RAM (d1) [ 34.662499] HOLE: 00000000:27800000 - 00000000:fc000000 (d1) [ 34.662545] [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d1) [ 34.662739] Invoking SeaBIOS ... (XEN) [ 34.662742] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 0 (XEN) [ 34.662742] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 0 (XEN) [ 34.662844] [HVM:1.0] <hvm_mov_to_cr> CR0, value = 11 (XEN) [ 34.662845] [HVM:1.0] <hvm_set_cr0> Update CR0 value = 11 (XEN) [ 34.763093] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.823098] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.823161] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 34.823989] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 35.373074] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 35.373188] [HVM:1.0] <vmx_restore_guest_msrs> restore guest's EFER with value 0 (XEN) [ 35.464356] Failed vm entry (exit reason 0x80000021) caused by invalid guest state (0). (XEN) [ 35.464357] ************* VMCS Area ************** (XEN) [ 35.464358] *** Guest State *** (XEN) [ 35.464359] CR0: actual=0x0000000000000039, shadow=0x0000000000000011, gh_mask=ffffffffffffffff (XEN) [ 35.464361] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffffff (XEN) [ 35.464361] CR3: actual=0x0000000000800000, target_count=0 (XEN) [ 35.464362] target0=0000000000000000, target1=0000000000000000 (XEN) [ 35.464363] target2=0000000000000000, target3=0000000000000000 (XEN) [ 35.464364] RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = 0x0000000100000000 (0x0000000100000000) (XEN) [ 35.464365] RFLAGS=0x0000000000000006 (0x0000000000000006) DR7 = 0x0000000000000400 (XEN) [ 35.464366] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) [ 35.464368] CS: sel=0x0008, attr=0x0c09b, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464369] DS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464370] SS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464371] ES: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464372] FS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464373] GS: sel=0x0010, attr=0x0c093, limit=0xffffffff, base=0x0000000000000000 (XEN) [ 35.464374] GDTR: limit=0x00000037, base=0x00000000000f6d80 (XEN) [ 35.464375] LDTR: sel=0x0000, attr=0x00082, limit=0x00000000, base=0x0000000000000000 (XEN) [ 35.464376] IDTR: limit=0x00000000, base=0x00000000000f6dbe (XEN) [ 35.464377] TR: sel=0x0000, attr=0x0008b, limit=0x000000ff, base=0x0000000000000000 (XEN) [ 35.464378] Guest PAT = 0x0007040600070406 (XEN) [ 35.464379] TSC Offset = ffffff71374d1298 (XEN) [ 35.464379] DebugCtl=0000000000000000 DebugExceptions=0000000000000000 (XEN) [ 35.464380] Interruptibility=0000 ActivityState=0000 (XEN) [ 35.464381] *** Host State *** (XEN) [ 35.464382] RSP = 0xffff83080ca97f90 RIP = 0xffff82d0801f5ae0 (XEN) [ 35.464383] CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040 (XEN) [ 35.464384] FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff83080caa2c80 (XEN) [ 35.464385] GDTBase=ffff83080ca96000 IDTBase=ffff83080caa1000 (XEN) [ 35.464386] CR0=000000008005003b CR3=000000070bf75000 CR4=00000000000426f0 (XEN) [ 35.464388] Sysenter RSP=ffff83080ca97fc0 CS:RIP=e008:ffff82d080237550 (XEN) [ 35.464388] Host PAT = 0x0000050100070406 (XEN) [ 35.464389] *** Control State *** (XEN) [ 35.464390] PinBased=0000003f CPUBased=b6a065fe SecondaryExec=000000eb (XEN) [ 35.464391] EntryControls=000051ff ExitControls=000fefff (XEN) [ 35.464392] ExceptionBitmap=000600c2 (XEN) [ 35.464392] VMEntry: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 35.464393] VMExit: intr_info=00000000 errcode=00000000 ilen=00000000 (XEN) [ 35.464394] reason=80000021 qualification=00000000 (XEN) [ 35.464395] IDTVectoring: info=00000000 errcode=00000000 (XEN) [ 35.464395] TPR Threshold = 0x00 (XEN) [ 35.464396] EPT pointer = 0x0000000707f0301e (XEN) [ 35.464397] Virtual processor ID = 0x0007 (XEN) [ 35.464398] ************************************** (XEN) [ 35.464398] domain_crash called from vmx.c:2505 (XEN) [ 35.464399] Domain 1 (vcpu#0) crashed on cpu#3: (XEN) [ 35.464401] ----[ Xen-4.5.2 x86_64 debug=n Not tainted ]---- (XEN) [ 35.464402] CPU: 3 (XEN) [ 35.464403] RIP: 0008:[<0000000100000000>] (XEN) [ 35.464404] RFLAGS: 0000000000000006 CONTEXT: hvm guest (d1v0) (XEN) [ 35.464406] rax: 0000000000000000 rbx: 0000000000000000 rcx: 00000000ffff1720 (XEN) [ 35.464407] rdx: 0000000000000059 rsi: 0000000000000059 rdi: 0000000000000000 (XEN) [ 35.464408] rbp: 0000000000000000 rsp: 0000000000006fdc r8: 0000000000000000 (XEN) [ 35.464409] r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) [ 35.464409] r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000 (XEN) [ 35.464410] r15: 0000000000000000 cr0: 0000000000000011 cr4: 0000000000000000 (XEN) [ 35.464411] cr3: 0000000000800000 cr2: 0000000000000000 (XEN) [ 35.464412] ds: 0010 es: 0010 fs: 0010 gs: 0010 ss: 0010 cs: 0008 [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 0:31 ` Atom2 @ 2015-11-19 1:06 ` Andrew Cooper 2015-11-19 20:02 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-19 1:06 UTC (permalink / raw) To: Atom2, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel On 19/11/2015 00:31, Atom2 wrote: > Am 19.11.15 um 00:17 schrieb Andrew Cooper: >> On 18/11/2015 22:51, Atom2 wrote: >>> Am 17.11.15 um 00:10 schrieb Atom2: > [big snip] >>> Hi Andrew, >>> as promised I have again tried with a debug build and the results are >>> very mixed. I initially tried to better understand what the debug USE >>> flag actually does in gentoo and my understanding (after reading the >>> so called ebuilds) is now that the XEN hypervisor will be built by >>> adding a gcc option of "debug=y" - and that's what should compile a >>> debug build - right? >> Yes indeed. >> >>> So I went on and again enabled the debug USE flag plus gdb symbols and >>> rebuilt the hypervisor in the hope that this created a valid and >>> working debug build. >>> >>> It, however, seems there's another problem lurking somewhere which >>> only manifests itself when I boot from the debug build of the >>> hypervisor. >> You did manage to get at least one decent log from a properly >> debugbuild. >> >> However, all we need is the hvm_debug output. This patch: >> >> ---8<--- >> diff --git a/xen/include/asm-x86/hvm/support.h >> b/xen/include/asm-x86/hvm/support.h >> index 05ef5c5..7a8fbb5 100644 >> --- a/xen/include/asm-x86/hvm/support.h >> +++ b/xen/include/asm-x86/hvm/support.h >> @@ -28,7 +28,7 @@ >> >> #define HVM_DELIVER_NO_ERROR_CODE -1 >> >> -#ifndef NDEBUG >> +#if 1 >> #define DBG_LEVEL_0 (1 << 0) >> #define DBG_LEVEL_1 (1 << 1) >> #define DBG_LEVEL_2 (1 << 2) >> ---8<--- >> >> Will enable hvm_debug in a non-debug build of hypervisor. Can you try >> that please? > Done. Please find the xl dmesg output attached to this mail. I guess > this time it is really what you were expecting. Whether it does make > sense though, might be a different issue. But I am confident in your > abilities to figure out what's going on. Thanks! That is what I was looking for. Sadly, it is less useful than I was hoping. The guest is not appearing to do anything interesting which causes the bad state; it is almost a full second between the previous action of note, and the crash. Can you email me the bad HVMLoader binary please? ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 1:06 ` Andrew Cooper @ 2015-11-19 20:02 ` Atom2 2015-11-19 23:53 ` Andrew Cooper 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-19 20:02 UTC (permalink / raw) To: Andrew Cooper, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel Am 19.11.15 um 02:06 schrieb Andrew Cooper: > Thanks! That is what I was looking for. > > Sadly, it is less useful than I was hoping. The guest is not appearing > to do anything interesting which causes the bad state; it is almost a > full second between the previous action of note, and the crash. > > Can you email me the bad HVMLoader binary please? Hi Andrew, Sure I can email the binary. What version of the HVMLoader do you want me to send to you? Should this be one with the debug option and debug symbols or a standard build without any of those? I assume we are talking about amd64 - right? Given the recent findings do you still want me to boot with minimal command line options to rule out an interaction with the options as suggested in an earlier answer? I can certainly do this, but would need to reconfigure certain things as both my HVM domUs require PCI passthrough devices (which you have stripped off the suggested minimal command line) to be available. Failing to see those devices puts those domUs into an unconfigured state and they re-start their initial setup process. Thanks Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 20:02 ` Atom2 @ 2015-11-19 23:53 ` Andrew Cooper 2015-11-24 11:53 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-19 23:53 UTC (permalink / raw) To: Atom2, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel On 19/11/2015 20:02, Atom2 wrote: > Am 19.11.15 um 02:06 schrieb Andrew Cooper: >> Thanks! That is what I was looking for. >> >> Sadly, it is less useful than I was hoping. The guest is not appearing >> to do anything interesting which causes the bad state; it is almost a >> full second between the previous action of note, and the crash. >> >> Can you email me the bad HVMLoader binary please? > Hi Andrew, > Sure I can email the binary. What version of the HVMLoader do you want > me to send to you? Should this be one with the debug option and debug > symbols or a standard build without any of those? I assume we are > talking about amd64 - right? hvmloader is always a 32bit binary, no matter what your host environment is. I would like any of the ones which reliably crash for you, preferably debug if that is available. > > Given the recent findings do you still want me to boot with minimal > command line options to rule out an interaction with the options as > suggested in an earlier answer? No - this is unnecessary now. > > I can certainly do this, but would need to reconfigure certain things > as both my HVM domUs require PCI passthrough devices (which you have > stripped off the suggested minimal command line) to be available. > Failing to see those devices puts those domUs into an unconfigured > state and they re-start their initial setup process. Don't worry - Jan figured this out from the disassembly, which I admittedly missed. It would be nice to see your vm's .cfg file to help me reproduce the issue. ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 23:53 ` Andrew Cooper @ 2015-11-24 11:53 ` Atom2 0 siblings, 0 replies; 43+ messages in thread From: Atom2 @ 2015-11-24 11:53 UTC (permalink / raw) To: Andrew Cooper, Konrad Rzeszutek Wilk; +Cc: Doug Goldstein, xen-devel [-- Attachment #1: Type: text/plain, Size: 2445 bytes --] Am 20.11.15 um 00:53 schrieb Andrew Cooper: > On 19/11/2015 20:02, Atom2 wrote: >> Am 19.11.15 um 02:06 schrieb Andrew Cooper: >>> Thanks! That is what I was looking for. >>> >>> Sadly, it is less useful than I was hoping. The guest is not appearing >>> to do anything interesting which causes the bad state; it is almost a >>> full second between the previous action of note, and the crash. >>> >>> Can you email me the bad HVMLoader binary please? >> Hi Andrew, >> Sure I can email the binary. What version of the HVMLoader do you want >> me to send to you? Should this be one with the debug option and debug >> symbols or a standard build without any of those? I assume we are >> talking about amd64 - right? > hvmloader is always a 32bit binary, no matter what your host environment > is. I would like any of the ones which reliably crash for you, > preferably debug if that is available. Hi Andrew, appologies for my delay in responding. I have just mailed you the crashing hvmloader off-list using my main mail address. It is the debug version from xen-4.5.2 together with symbols (as splitdebug) using the non-working seabios-1.8.2 - all packed up in a compressed tar file using relative names and maintaining the directory structure required for splitdebug to work. If you would also like me to send you the failing seabios binary separately, just let me know. My understanding, however, is that seabios is anyways emebedded in the hvmloader binary. >> Given the recent findings do you still want me to boot with minimal >> command line options to rule out an interaction with the options as >> suggested in an earlier answer? > No - this is unnecessary now. > >> I can certainly do this, but would need to reconfigure certain things >> as both my HVM domUs require PCI passthrough devices (which you have >> stripped off the suggested minimal command line) to be available. >> Failing to see those devices puts those domUs into an unconfigured >> state and they re-start their initial setup process. > Don't worry - Jan figured this out from the disassembly, which I > admittedly missed. > > It would be nice to see your vm's .cfg file to help me reproduce the issue. Attached please find the config file for one of the HVM virtual machines that crashes with the hmvloader binary sent to you by mail. The vm, btw, is running the pfsense firewall using FreeBSD. Any more information required - just ask. Many thanks Atom2 [-- Attachment #2: pfsense.cfg --] [-- Type: text/plain, Size: 549 bytes --] builder = 'hvm' cpus = '2-7' vcpus = 2 cpu_weight = 512 memory = 640 name = 'pfsense' disk = [ 'vdev=xvda,format=raw,access=rw,target=/etc/xen/guests/disk.d/pfsense.disk' ] vif = [ 'mac=00:16:3e:a1:64:01,bridge=xenbr0,type=vif,vifname=pfsense.0,script=vif-bridge.noTXoffload' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' localtime = 0 boot = 'c' vnc = 1 vnclisten = '127.0.0.1' vncpasswd = '' keymap = 'de' nographic = 1 serial = 'pty' nx = 1 pci = [ '04:00.0', '0a:08.0', '0a:0b.0' ] [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-18 23:17 ` Andrew Cooper 2015-11-19 0:31 ` Atom2 @ 2015-11-19 10:24 ` Jan Beulich 2015-11-19 10:38 ` Andrew Cooper 1 sibling, 1 reply; 43+ messages in thread From: Jan Beulich @ 2015-11-19 10:24 UTC (permalink / raw) To: Andrew Cooper, Atom2; +Cc: Doug Goldstein, xen-devel >>> On 19.11.15 at 00:17, <andrew.cooper3@citrix.com> wrote: > The disassembly of do_IRQ now looks like a plausible function, but the > consistently faulting address has no plausible way of generating a > double fault. I suspect therefore that something has caused memory > corruption in Xen .text section. Dump of assembler code for function do_IRQ: 0xffff82d080176577 <+0>: push %rbp 0xffff82d080176578 <+1>: mov %rsp,%rbp 0xffff82d08017657b <+4>: push %r15 0xffff82d08017657d <+6>: push %r14 0xffff82d08017657f <+8>: push %r13 0xffff82d080176581 <+10>: push %r12 0xffff82d080176583 <+12>: push %rbx 0xffff82d080176584 <+13>: lea -0x1058(%rsp),%rsp 0xffff82d08017658c <+21>: orq $0x0,(%rsp) 0xffff82d080176591 <+26>: lea 0x1020(%rsp),%rsp The orq surely has potential for causing a double fault, if %rsp is near the stack limit. The two LEAs look suspect, presumably a result of some non-standard option passed to gcc. Removing that option might already be a step forward. Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 10:24 ` Jan Beulich @ 2015-11-19 10:38 ` Andrew Cooper 2015-11-19 19:51 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Andrew Cooper @ 2015-11-19 10:38 UTC (permalink / raw) To: Jan Beulich, Atom2; +Cc: Doug Goldstein, xen-devel On 19/11/15 10:24, Jan Beulich wrote: >>>> On 19.11.15 at 00:17, <andrew.cooper3@citrix.com> wrote: >> The disassembly of do_IRQ now looks like a plausible function, but the >> consistently faulting address has no plausible way of generating a >> double fault. I suspect therefore that something has caused memory >> corruption in Xen .text section. > Dump of assembler code for function do_IRQ: > 0xffff82d080176577 <+0>: push %rbp > 0xffff82d080176578 <+1>: mov %rsp,%rbp > 0xffff82d08017657b <+4>: push %r15 > 0xffff82d08017657d <+6>: push %r14 > 0xffff82d08017657f <+8>: push %r13 > 0xffff82d080176581 <+10>: push %r12 > 0xffff82d080176583 <+12>: push %rbx > 0xffff82d080176584 <+13>: lea -0x1058(%rsp),%rsp > 0xffff82d08017658c <+21>: orq $0x0,(%rsp) > 0xffff82d080176591 <+26>: lea 0x1020(%rsp),%rsp > > The orq surely has potential for causing a double fault, if %rsp is > near the stack limit. The two LEAs look suspect, presumably a > result of some non-standard option passed to gcc. Removing that > option might already be a step forward. Actually yes - that is a huge quantity of stack usage. (The actual behaviour looks very suspect - it appears to be completely pointless). The #DF handler reports that %rsp in the exception frame is within range. Having said that, (XEN) [ 2.788209] rbp: ffff83080ca8ed78 rsp: ffff83080ca8dcf8 r8: ffff83080ca9d558 ... (XEN) [ 2.837474] Valid stack range: ffff83080ca8e000-ffff83080ca90000, sp=ffff83080ca8dcf8, tss.esp0=ffff83080ca8ffc0 (XEN) [ 2.848969] No stack overflow detected. Skipping stack trace. In this case, the stack pointer *is* out of range, and has hit the guard page. This means: 1) There is some bug in the stack overflow detection in the #DF handler. 2) Whatever options Gentoo compiles Xen with is sufficient to overflow the 8K hypervisor stack. ~Andrew ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 10:38 ` Andrew Cooper @ 2015-11-19 19:51 ` Atom2 2015-11-20 7:57 ` Jan Beulich 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-19 19:51 UTC (permalink / raw) To: Andrew Cooper, Jan Beulich; +Cc: Doug Goldstein, xen-devel Am 19.11.15 um 11:38 schrieb Andrew Cooper: > On 19/11/15 10:24, Jan Beulich wrote: >>>>> On 19.11.15 at 00:17, <andrew.cooper3@citrix.com> wrote: >>> The disassembly of do_IRQ now looks like a plausible function, but the >>> consistently faulting address has no plausible way of generating a >>> double fault. I suspect therefore that something has caused memory >>> corruption in Xen .text section. >> Dump of assembler code for function do_IRQ: >> 0xffff82d080176577 <+0>: push %rbp >> 0xffff82d080176578 <+1>: mov %rsp,%rbp >> 0xffff82d08017657b <+4>: push %r15 >> 0xffff82d08017657d <+6>: push %r14 >> 0xffff82d08017657f <+8>: push %r13 >> 0xffff82d080176581 <+10>: push %r12 >> 0xffff82d080176583 <+12>: push %rbx >> 0xffff82d080176584 <+13>: lea -0x1058(%rsp),%rsp >> 0xffff82d08017658c <+21>: orq $0x0,(%rsp) >> 0xffff82d080176591 <+26>: lea 0x1020(%rsp),%rsp >> >> The orq surely has potential for causing a double fault, if %rsp is >> near the stack limit. The two LEAs look suspect, presumably a >> result of some non-standard option passed to gcc. Removing that >> option might already be a step forward. Andrew, Jan - thanks again. In terms of non-standard options passed to gcc I have tried to make sense of what flags are actually being used during the build process. I am not absolutely sure, but I think the options passed to gcc are as follows: I do have system wide flags which are used for non-debug builds: CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,-O1 -Wl,--as-needed" for builds with debug symbols (using splitdebug) there are system wide overrides as follows: CFLAGS="-march=native -O2 -pipe -ggdb" CXXFLAGS="${CFLAGS}" LDFLAGS: I'd assume that this inherits its value from the system wide setting of LDFLAGS for xen (the hypervisor) the build system seems to do the following: CFLAGS="" (i.e. unset CFLAGS) to me this indicates that the rest stays untouched (i.e. either standard or debug flags) for xen-tools (includes e.g. hvmloader) the build system appears to to the following: CFLAGS="" (i.e. unset CFLAGS) CXXFLAGS="${CXXFLAGS} -fno-strict-overflow" LDFLAGS="" (i.e. unset LDFLAGS) So I think there's probably nothing really fancy in my options to gcc. > Actually yes - that is a huge quantity of stack usage. > > (The actual behaviour looks very suspect - it appears to be completely > pointless). > > The #DF handler reports that %rsp in the exception frame is within > range. Having said that, > > (XEN) [ 2.788209] rbp: ffff83080ca8ed78 rsp: ffff83080ca8dcf8 > r8: ffff83080ca9d558 > ... > (XEN) [ 2.837474] Valid stack range: > ffff83080ca8e000-ffff83080ca90000, sp=ffff83080ca8dcf8, > tss.esp0=ffff83080ca8ffc0 > (XEN) [ 2.848969] No stack overflow detected. Skipping stack trace. > > In this case, the stack pointer *is* out of range, and has hit the guard > page. > > This means: > 1) There is some bug in the stack overflow detection in the #DF handler. > 2) Whatever options Gentoo compiles Xen with is sufficient to overflow > the 8K hypervisor stack. Thanks Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-19 19:51 ` Atom2 @ 2015-11-20 7:57 ` Jan Beulich 2015-11-24 10:32 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Jan Beulich @ 2015-11-20 7:57 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, Doug Goldstein, xen-devel >>> On 19.11.15 at 20:51, <ariel.atom2@web2web.at> wrote: > In terms of non-standard options passed to gcc I have tried to make sense of > what flags are actually being used during the build process. I am not > absolutely sure, but I think the options passed to gcc are as follows: > > I do have system wide flags which are used for non-debug builds: > CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" > CXXFLAGS="${CFLAGS}" > LDFLAGS="-Wl,-O1 -Wl,--as-needed" > > for builds with debug symbols (using splitdebug) there are system wide > overrides as follows: > CFLAGS="-march=native -O2 -pipe -ggdb" > CXXFLAGS="${CFLAGS}" > LDFLAGS: I'd assume that this inherits its value from the system wide > setting of LDFLAGS > > for xen (the hypervisor) the build system seems to do the following: > CFLAGS="" (i.e. unset CFLAGS) > to me this indicates that the rest stays untouched (i.e. either standard or > debug flags) > > for xen-tools (includes e.g. hvmloader) the build system appears to to the > following: > CFLAGS="" (i.e. unset CFLAGS) > CXXFLAGS="${CXXFLAGS} -fno-strict-overflow" > LDFLAGS="" (i.e. unset LDFLAGS) > > So I think there's probably nothing really fancy in my options to gcc. What you list above seems pretty normal indeed. However, why don't you simply look at the options actually passed to gcc when building the hypervisor. And you should also not forget that your distro's gcc build itself may have certain non-standard option settings. For the odd stack accesses at function entry I think you should be able to see whether this is a compiler default by looking at some random, not overly trivial object file known to have been compiled by the exact same compiler. Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-20 7:57 ` Jan Beulich @ 2015-11-24 10:32 ` Atom2 2015-11-24 10:43 ` Jan Beulich 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-24 10:32 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Doug Goldstein, xen-devel [-- Attachment #1: Type: text/plain, Size: 995 bytes --] Am 20.11.15 um 08:57 schrieb Jan Beulich: > What you list above seems pretty normal indeed. However, why don't you > simply look at the options actually passed to gcc when building the > hypervisor. And you should also not forget that your distro's gcc > build itself may have certain non-standard option settings. For the > odd stack accesses at function entry I think you should be able to see > whether this is a compiler default by looking at some random, not > overly trivial object file known to have been compiled by the exact > same compiler. Jan Hi Jan, sorry for my delay in replying. Given that your answer suggests it might not be as trivial as I thought, I decided to simply re-compile the crashing xen (including symbols and the debug option) and attach the complete build log which to me looks as if it includes all flags used for every object built. The file is long, thus compressed, but I am sure your are able to immeditately spot what to look for. Thanks Atom2 [-- Attachment #2: build.log.gz --] [-- Type: application/gzip, Size: 16872 bytes --] [-- Attachment #3: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-24 10:32 ` Atom2 @ 2015-11-24 10:43 ` Jan Beulich 2015-11-27 22:51 ` Atom2 0 siblings, 1 reply; 43+ messages in thread From: Jan Beulich @ 2015-11-24 10:43 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, Doug Goldstein, xen-devel >>> On 24.11.15 at 11:32, <ariel.atom2@web2web.at> wrote: > Am 20.11.15 um 08:57 schrieb Jan Beulich: >> What you list above seems pretty normal indeed. However, why don't you >> simply look at the options actually passed to gcc when building the >> hypervisor. And you should also not forget that your distro's gcc >> build itself may have certain non-standard option settings. For the >> odd stack accesses at function entry I think you should be able to see >> whether this is a compiler default by looking at some random, not >> overly trivial object file known to have been compiled by the exact >> same compiler. Jan > Hi Jan, > sorry for my delay in replying. Given that your answer suggests it might > not be as trivial as I thought, I decided to simply re-compile the > crashing xen (including symbols and the debug option) and attach the > complete build log which to me looks as if it includes all flags used > for every object built. The file is long, thus compressed, but I am sure > your are able to immeditately spot what to look for. Taking a random object out of that log, I can't see any non-standard option passed to the compiler, so I have to assume this is its default behavior (i.e. determined at build time, or established by extra patches). Did you check the result of a random, non-trivial C file from other than the Xen tree? Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-24 10:43 ` Jan Beulich @ 2015-11-27 22:51 ` Atom2 2015-11-30 9:04 ` Jan Beulich 0 siblings, 1 reply; 43+ messages in thread From: Atom2 @ 2015-11-27 22:51 UTC (permalink / raw) To: Jan Beulich; +Cc: Andrew Cooper, Doug Goldstein, xen-devel Am 24.11.15 um 11:43 schrieb Jan Beulich: > Taking a random object out of that log, I can't see any non-standard > option passed to the compiler, so I have to assume this is its default > behavior (i.e. determined at build time, or established by extra > patches). Did you check the result of a random, non-trivial C file from > other than the Xen tree? Hi Jan, today I update a few packages like net-tools, curl, lipcre, and python and none of these packages did have any strange compiler options. It appeared that actually all had "-march=native -O2 -pipe -fomit-frame-pointer" which is the globally defined standard on my system and thus fully expected. A few obviously had package specific additions (i.e. python added -fPIC -fwrapv), but nothing really strange in my view. Any more information you require or would you want to see any such build log for yourself? Thanks Atom2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-27 22:51 ` Atom2 @ 2015-11-30 9:04 ` Jan Beulich 0 siblings, 0 replies; 43+ messages in thread From: Jan Beulich @ 2015-11-30 9:04 UTC (permalink / raw) To: Atom2; +Cc: Andrew Cooper, Doug Goldstein, xen-devel >>> On 27.11.15 at 23:51, <ariel.atom2@web2web.at> wrote: > Am 24.11.15 um 11:43 schrieb Jan Beulich: >> Taking a random object out of that log, I can't see any non-standard >> option passed to the compiler, so I have to assume this is its default >> behavior (i.e. determined at build time, or established by extra >> patches). Did you check the result of a random, non-trivial C file from >> other than the Xen tree? > Hi Jan, > today I update a few packages like net-tools, curl, lipcre, and python > and none of these packages did have any strange compiler options. It > appeared that actually all had "-march=native -O2 -pipe > -fomit-frame-pointer" which is the globally defined standard on my > system and thus fully expected. A few obviously had package specific > additions (i.e. python added -fPIC -fwrapv), but nothing really strange > in my view. > > Any more information you require or would you want to see any such build > log for yourself? I definitely do not want to see any build logs; I also do not _require_ and more information: I think I've provided enough guidance for you to investigate the odd compiler behavior at your end. Jan ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 1:05 ` Atom2 2015-11-16 15:31 ` Konrad Rzeszutek Wilk @ 2015-11-16 19:47 ` Doug Goldstein 2015-11-16 20:14 ` Atom2 1 sibling, 1 reply; 43+ messages in thread From: Doug Goldstein @ 2015-11-16 19:47 UTC (permalink / raw) To: Atom2, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 10371 bytes --] On 11/15/15 7:05 PM, Atom2 wrote: > Am 15.11.15 um 21:12 schrieb Doug Goldstein: >> On 11/14/15 6:14 PM, Atom2 wrote: >>> Am 14.11.15 um 21:32 schrieb Andrew Cooper: >>>> On 14/11/2015 00:16, Atom2 wrote: >>>>> Am 13.11.15 um 11:09 schrieb Andrew Cooper: >>>>>> On 13/11/15 07:25, Jan Beulich wrote: >>>>>>>>>> On 13.11.15 at 00:00, <ariel.atom2@web2web.at> wrote: >>>>>>>> Am 12.11.15 um 17:43 schrieb Andrew Cooper: >>>>>>>>> On 12/11/15 14:29, Atom2 wrote: >>>>>>>>>> Hi Andrew, >>>>>>>>>> thanks for your reply. Answers are inline further down. >>>>>>>>>> >>>>>>>>>> Am 12.11.15 um 14:01 schrieb Andrew Cooper: >>>>>>>>>>> On 12/11/15 12:52, Jan Beulich wrote: >>>>>>>>>>>>>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >>>>>>>>>>>>> After the upgrade HVM domUs appear to no longer work - >>>>>>>>>>>>> regardless >>>>>>>>>>>>> of the >>>>>>>>>>>>> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 >>>>>>>>>>>>> kernel); PV >>>>>>>>>>>>> domUs, however, work just fine as before on both dom0 kernels. >>>>>>>>>>>>> >>>>>>>>>>>>> xl dmesg shows the following information after the first >>>>>>>>>>>>> crashed HVM >>>>>>>>>>>>> domU which is started as part of the machine booting up: >>>>>>>>>>>>> [...] >>>>>>>>>>>>> (XEN) Failed vm entry (exit reason 0x80000021) caused by >>>>>>>>>>>>> invalid guest >>>>>>>>>>>>> state (0). >>>>>>>>>>>>> (XEN) ************* VMCS Area ************** >>>>>>>>>>>>> (XEN) *** Guest State *** >>>>>>>>>>>>> (XEN) CR0: actual=0x0000000000000039, >>>>>>>>>>>>> shadow=0x0000000000000011, >>>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>>> (XEN) CR4: actual=0x0000000000002050, >>>>>>>>>>>>> shadow=0x0000000000000000, >>>>>>>>>>>>> gh_mask=ffffffffffffffff >>>>>>>>>>>>> (XEN) CR3: actual=0x0000000000800000, target_count=0 >>>>>>>>>>>>> (XEN) target0=0000000000000000, target1=0000000000000000 >>>>>>>>>>>>> (XEN) target2=0000000000000000, target3=0000000000000000 >>>>>>>>>>>>> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >>>>>>>>>>>>> 0x0000000100000000 (0x0000000100000000) >>>>>>>>>>>> Other than RIP looking odd for a guest still in non-paged >>>>>>>>>>>> protected >>>>>>>>>>>> mode I can't seem to spot anything wrong with guest state. >>>>>>>>>>> odd? That will be the source of the failure. >>>>>>>>>>> >>>>>>>>>>> Out of long mode, the upper 32bit of %rip should all be zero, >>>>>>>>>>> and it >>>>>>>>>>> should not be possible to set any of them. >>>>>>>>>>> >>>>>>>>>>> I suspect that the guest has exited for emulation, and there >>>>>>>>>>> has been a >>>>>>>>>>> bad update to %rip. The alternative (which I hope is not the >>>>>>>>>>> case) is >>>>>>>>>>> that there is a hardware errata which allows the guest to >>>>>>>>>>> accidentally >>>>>>>>>>> get it self into this condition. >>>>>>>>>>> >>>>>>>>>>> Are you able to rerun with a debug build of the hypervisor? >>> [big snip] >>>>>>>>>> Now _without_ the debug USE flag, but with debug information in >>>>>>>>>> the binary (I used splitdebug), all is back to where >>>>>>>>>> the problem >>>>>>>>>> started off (i.e. the system boots without issues >>>>>>>>>> until such >>>>>>>>>> time it starts a HVM domU which then crashes; PV >>>>>>>>>> domUs are >>>>>>>>>> working). I have attached the latest "xl dmesg" >>>>>>>>>> output with the >>>>>>>>>> timing information included. >>>>>>>>>> >>>>> I hope any of this makes sense to you. >>>>> >>>>> Again many thanks and best regards >>>>> >>>> Right - it would appear that the USE flag is definitely not what you >>>> wanted, and causes bad compilation for Xen. The do_IRQ disassembly >>>> you sent is a the result of disassembling a whole block of zeroes. >>>> Sorry for leading you on a goose chase - the double faults will be the >>>> product of bad compilation, rather than anything to do with your >>>> specific problem. >>> Hi Andrew, >>> there's absolutely no need to appologize as it is me who asked for help >>> and you who generously stepped in and provided it. I really do >>> appreciate your help and it is for me, as the one seeking help, to >>> provide all the information you deem necessary and you ask for. >>>> However, the final log you sent (dmesg) is using a debug Xen, which is >>>> what I was attempting to get you to do originally. >>> Next time I know better how to arrive at a debug XEN. It's all about >>> learning. >>>> We still observe that the VM ends up in 32bit non-paged mode but with >>>> an RIP with bit 32 set, which is an invalid state to be in. However, >>>> there was nothing particularly interesting in the extra log >>>> information. >>>> >>>> Please can you rerun with "hvm_debug=0xc3f", which will cause far more >>>> logging to occur to the console while the HVM guest is running. That >>>> might show some hints. >>> I haven't done that yet - but please see my next paragraph. If you are >>> still interested in this, for whatever reason, I am clearly more than >>> happy to rerun with your suggested option and provide that information >>> as well. >>>> Also, the fact that this occurs just after starting SeaBIOS is >>>> interesting. As you have switched versions of Xen, you have also >>>> switched hvmloader, which contains the SeaBIOS binary embedded in it. >>>> Would you be able to compile both 4.5.1 and 4.5.2 and switch the >>>> hvmloader binaries in use. It would be very interesting to see >>>> whether the failure is caused by the hvmloader binary or the >>>> hypervisor. (With `xl`, you can use >>>> firmware_override="/full/path/to/firmware" to override the default >>>> hvmloader). >>> Your analysis was absolutely spot on. After re-thinking this for a >>> moment, I thought going down that route first would make a lot of sense >>> as PV guests still do work and one of the differences to HVM domUs is >>> that the former do _not_ require SeaBIOS. Looking at my log files of >>> installed packages confirmed an upgrade from SeaBIOS 1.7.5 to 1.8.2 in >>> the relevant timeframe which obviously had not made it to the hvmloader >>> of xen-4.5.1 as I did not re-compile xen after the upgrade of SeaBIOS. >>> >>> So I re-compiled xen-4.5.1 (obviously now using the installed SeaBIOS >>> 1.8.2) and the same error as with xen-4.5.2 popped up - and that seemed >>> to strongly indicate that there indeed might be an issue with SeaBIOS as >>> this probably was the only variable that had changed from the original >>> install of xen-4.5.1. >>> >>> My next step was to downgrade SeaBIOS to 1.7.5 and to re-compile >>> xen-4.5.1. Voila, the system was again up and running. While still >>> having SeaBIOS 1.7.5 installed, I also re-compiled xen-4.5.2 and ... you >>> probably guessed it ... the problem was gone: The system boots up with >>> no issues and everything is fine again. >>> >>> So in a nutshell: There seems to be a problem with SeaBIOS 1.8.2 >>> preventing HVM doamins from successfully starting up. I don't know what >>> this is triggered from, if this is specific to my hardware or whether >>> something else in my environment is to blame. >>> >>> In any case, I am again more than happy to provide data / run a few >>> tests should you wish to get to the grounds of this. >>> >>> I do owe you a beer (or any other drink) should you ever be at my >>> location (i.e. Vienna, Austria). >>> >>> Many thanks again for your analysis and your first class support. Xen >>> and their people absolutely rock! >>> >>> Atom2 >> I'm a little late to the thread but can you send me (you can do it >> off-list if you'd like) the USE flags you used for xen, xen-tools and >> seabios? Also emerge --info. You can kill two birds with one stone by >> using emerge --info xen. > Hi Doug, > here you go: Thanks. I'll use your configuration as a test point to update a few things with regard to the Gentoo ebuilds. I'm not the maintainer of Xen and SeaBIOS but I don't think the maintainers will have much issue with the changes. > USE flags: > app-emulation/xen-4.5.2-r1::gentoo USE="-custom-cflags -debug -efi > -flask -xsm" > app-emulation/xen-tools-4.5.2::gentoo USE="hvm pam pygrub python qemu > screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) > -ovmf -static-libs -system-qemu" PYTHON_TARGETS="python2_7" > sys-firmware/seabios-1.7.5::gentoo USE="binary" So looking at how SeaBIOS and friends are built I think we have an issue that needs to be addressed. That being said, you wouldn't have this issue if you did USE="-system-seabios -system-qemu". I believe you would also be ok if you had done USE="system-seabios system-qemu". But after a quick look at everything USE="system-seabios -system-qemu" will definitely do the wrong thing. > emerge --info: Please see the attached file >> I'm not too familiar with the xen ebuilds but I was pretty sure that >> xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS >> and builds it so that it remains consistent. But obviously your >> experience shows otherwise. > You are right, it's xen-tools that builds hvmloader. If I remember > correctly, the "system-seabios" USE flag (for xen-tools) specifies > whether sys-firmware/seabios is used and the latter downloads SeaBIOS in > it's binary form provided its "binary" USE flag is set. At least that's > my understanding. >> I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and >> your info would be helpful. > Great. Whatever makes gentoo and xen stronger will be awesome. What > immediately springs to mind is to create a separate hvmloader package > and slot that (that's just an idea and probably not fully thought > through, but ss far as I understood Andrew, it would then be possible to > specify the specific firmware version [i.e. hvmloader] to use on xl's > command line by using firmware_override="full/path/to/firmware"). > > I also found out that an upgrade to sys-firmware/seabios obviously does > not trigger an automatic re-emerge of xen-tools and thus hvmloader. > Shouldn't this also happen automatically as xen-tools depends on seabios? > > Thanks and best regards Atom2 > > > P.S. If you prefer to take this off-list, just reply to my mail address. -- Doug Goldstein [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-16 19:47 ` Doug Goldstein @ 2015-11-16 20:14 ` Atom2 0 siblings, 0 replies; 43+ messages in thread From: Atom2 @ 2015-11-16 20:14 UTC (permalink / raw) To: Doug Goldstein, xen-devel Am 16.11.15 um 20:47 schrieb Doug Goldstein: > I'm a little late to the thread but can you send me (you can do it > off-list if you'd like) the USE flags you used for xen, xen-tools and > seabios? Also emerge --info. You can kill two birds with one stone by > using emerge --info xen. >> Hi Doug, >> here you go: > Thanks. I'll use your configuration as a test point to update a few > things with regard to the Gentoo ebuilds. I'm not the maintainer of Xen > and SeaBIOS but I don't think the maintainers will have much issue with > the changes. Hi Doug, that sounds great. If you require any more information, please do not hesitate to contact me - either by mail or through this thread. >> USE flags: >> app-emulation/xen-4.5.2-r1::gentoo USE="-custom-cflags -debug -efi >> -flask -xsm" >> app-emulation/xen-tools-4.5.2::gentoo USE="hvm pam pygrub python qemu >> screen system-seabios -api -custom-cflags -debug -doc -flask (-ocaml) >> -ovmf -static-libs -system-qemu" PYTHON_TARGETS="python2_7" >> sys-firmware/seabios-1.7.5::gentoo USE="binary" > So looking at how SeaBIOS and friends are built I think we have an issue > that needs to be addressed. That being said, you wouldn't have this > issue if you did USE="-system-seabios -system-qemu". I believe you would > also be ok if you had done USE="system-seabios system-qemu". But after a > quick look at everything USE="system-seabios -system-qemu" will > definitely do the wrong thing. There was a reason why I did not use -system-seabios. The reason (and a discussion about the issues I was facing back then) can be found in this thread: http://lists.xenproject.org/archives/html/xen-users/2015-01/msg00103.html. This problem was then sorted by changing to the upstream SeaBIOS instead of the bundled version (described in http://lists.xenproject.org/archives/html/xen-users/2015-01/msg00131.html) by changing the USE flag. I don't know whether there were any relevant changes since xen-4.3.3, but at that point in time it appeared to be my only chance to keep my system up and running. Since then (January 2015) I did not find any reason to revert the USE flag back to -system-seabios as everything was working as expected - obviously up until now. Thanks Atom2 >> emerge --info: Please see the attached file >>> I'm not too familiar with the xen ebuilds but I was pretty sure that >>> xen-tools is what builds hvmloader and it downloads a copy of SeaBIOS >>> and builds it so that it remains consistent. But obviously your >>> experience shows otherwise. >> You are right, it's xen-tools that builds hvmloader. If I remember >> correctly, the "system-seabios" USE flag (for xen-tools) specifies >> whether sys-firmware/seabios is used and the latter downloads SeaBIOS in >> it's binary form provided its "binary" USE flag is set. At least that's >> my understanding. >>> I'm looking at some ideas to improve SeaBIOS packaging on Gentoo and >>> your info would be helpful. >> Great. Whatever makes gentoo and xen stronger will be awesome. What >> immediately springs to mind is to create a separate hvmloader package >> and slot that (that's just an idea and probably not fully thought >> through, but ss far as I understood Andrew, it would then be possible to >> specify the specific firmware version [i.e. hvmloader] to use on xl's >> command line by using firmware_override="full/path/to/firmware"). >> >> I also found out that an upgrade to sys-firmware/seabios obviously does >> not trigger an automatic re-emerge of xen-tools and thus hvmloader. >> Shouldn't this also happen automatically as xen-tools depends on seabios? >> >> Thanks and best regards Atom2 >> >> >> P.S. If you prefer to take this off-list, just reply to my mail address. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 2015-11-12 12:52 ` Jan Beulich 2015-11-12 13:01 ` Andrew Cooper @ 2015-11-12 14:12 ` Atom2 1 sibling, 0 replies; 43+ messages in thread From: Atom2 @ 2015-11-12 14:12 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel Hi Jan, many thanks for your reply. Answers are further down inline. Am 12.11.15 um 13:52 schrieb Jan Beulich: >>>> On 12.11.15 at 02:08, <ariel.atom2@web2web.at> wrote: >> After the upgrade HVM domUs appear to no longer work - regardless of the >> dom0 kernel (tested with both 3.18.9 and 4.1.7 as the dom0 kernel); PV >> domUs, however, work just fine as before on both dom0 kernels. >> >> xl dmesg shows the following information after the first crashed HVM >> domU which is started as part of the machine booting up: >> [...] >> (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest >> state (0). >> (XEN) ************* VMCS Area ************** >> (XEN) *** Guest State *** >> (XEN) CR0: actual=0x0000000000000039, shadow=0x0000000000000011, >> gh_mask=ffffffffffffffff >> (XEN) CR4: actual=0x0000000000002050, shadow=0x0000000000000000, >> gh_mask=ffffffffffffffff >> (XEN) CR3: actual=0x0000000000800000, target_count=0 >> (XEN) target0=0000000000000000, target1=0000000000000000 >> (XEN) target2=0000000000000000, target3=0000000000000000 >> (XEN) RSP = 0x0000000000006fdc (0x0000000000006fdc) RIP = >> 0x0000000100000000 (0x0000000100000000) > Other than RIP looking odd for a guest still in non-paged protected > mode I can't seem to spot anything wrong with guest state. > Considering that there was just a single HVM-related commit > between the two releases (which looks completely unrelated) I > wonder whether you're observing a problem that's a side effect > of something else, e.g. a build system change (compiler update or > alike). If that can be ruled out, I guess the only chance would be > for you to bisect for the offending commit. A few weeks ago there was an update of the gcc compiler from version 4.8.5 to 4.9.3. The old version of XEN (i.e. 4.5.1) was compiled in August on gcc-4.8.5. The current version xen-4.5.2 was compiled yesterday and obviously used gcc-4.9.3. I might try to re-compile with 4.8.5 again in case that makes any sense (gcc-4.8.5 is still installed in another slot on my system), but will first reply to Andrew as well. > > Are you observing this on more than one kind of system? Unfortunately this system is currently my only XEN system and it was rock-solid over the last couple of years with virtually no down-time once it was up and running with various XEN and dom0 kernel versions. > > Jan Many thanks Atom ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2015-11-30 9:04 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-12 1:08 HVM domains crash after upgrade from XEN 4.5.1 to 4.5.2 Atom2 2015-11-12 12:52 ` Jan Beulich 2015-11-12 13:01 ` Andrew Cooper 2015-11-12 14:29 ` Atom2 2015-11-12 15:32 ` Jan Beulich 2015-11-12 16:43 ` Andrew Cooper 2015-11-12 23:00 ` Atom2 2015-11-13 7:25 ` Jan Beulich 2015-11-13 10:09 ` Andrew Cooper 2015-11-14 0:16 ` Atom2 2015-11-14 20:32 ` Andrew Cooper 2015-11-15 0:14 ` Atom2 2015-11-15 15:12 ` Andrew Cooper 2015-11-16 0:39 ` Atom2 2015-11-16 10:02 ` Andrew Cooper 2015-11-15 20:12 ` Doug Goldstein 2015-11-16 1:05 ` Atom2 2015-11-16 15:31 ` Konrad Rzeszutek Wilk 2015-11-16 19:16 ` Atom2 2015-11-16 19:25 ` Konrad Rzeszutek Wilk 2015-11-16 19:39 ` Doug Goldstein 2015-11-16 19:47 ` Konrad Rzeszutek Wilk 2015-11-16 19:45 ` Atom2 2015-11-16 23:01 ` Andrew Cooper 2015-11-16 23:10 ` Atom2 2015-11-18 22:51 ` Atom2 2015-11-18 23:17 ` Andrew Cooper 2015-11-19 0:31 ` Atom2 2015-11-19 1:06 ` Andrew Cooper 2015-11-19 20:02 ` Atom2 2015-11-19 23:53 ` Andrew Cooper 2015-11-24 11:53 ` Atom2 2015-11-19 10:24 ` Jan Beulich 2015-11-19 10:38 ` Andrew Cooper 2015-11-19 19:51 ` Atom2 2015-11-20 7:57 ` Jan Beulich 2015-11-24 10:32 ` Atom2 2015-11-24 10:43 ` Jan Beulich 2015-11-27 22:51 ` Atom2 2015-11-30 9:04 ` Jan Beulich 2015-11-16 19:47 ` Doug Goldstein 2015-11-16 20:14 ` Atom2 2015-11-12 14:12 ` Atom2
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.