* Clarifying PVH mode requirements @ 2016-01-31 21:27 PGNet Dev 2016-02-01 3:47 ` PGNet Dev ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: PGNet Dev @ 2016-01-31 21:27 UTC (permalink / raw) To: xen-devel; +Cc: mukesh.rathor I run Xen 4.6 Dom0 rpm -qa | egrep -i "kernel-default-4|xen-4" kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 xen-4.6.0_08-405.1.x86_64 My guests are currently HVM in PVHVM mode; I'm exploring PVH. IIUC, for 4.6, this doc http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt instructs the following necessary changes: @ GRUBG cfg - GRUB_CMDLINE_XEN=" ..." + GRUB_CMDLINE_XEN=" dom0pvh ..." &, @ guest.cfg + pvh = 1 For my guest.cfg, currently in PVHVM mode, I have builder = 'hvm' xen_platform_pci = 1 device_model_version="qemu-xen" hap = 1 ... Q: Do any of these^^ params need to also change with the addition of pvh = 1 > At the moment HAP is required for PVH. As above, I've 'hap = 1' enabled. But checking cpu, hwinfo --cpu | egrep "Arch|Model" Arch: X86-64 Model: 6.60.3 "Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz" neither 'hap' nor 'emt' are specifically called out, egrep -wo 'vmx|lm|aes' /proc/cpuinfo | sort | uniq \ | sed -e 's/aes/Hardware encryption=Yes (&)/g' \ -e 's/lm/64 bit cpu=Yes (&)/g' -e 's/vmx/Intel hardware virtualization=Yes (&)/g' Hardware encryption=Yes (aes) 64 bit cpu=Yes (lm) egrep -wo 'hap|vmx|ept|vpid|npt|tpr_shadow|flexpriority|vnmi|lm|aes' /proc/cpuinfo | sort | uniq aes lm Iiuc, Intel introduced EPT with Nehalem arch, which preceds Haswell by ~ 5 years. Q: Am I out of luck re: PVH with more modern Haswell? Or is there a different check I should be running ? > At present the only PVH guest is an x86 64bit PV linux. Is this still current/true info? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-01-31 21:27 Clarifying PVH mode requirements PGNet Dev @ 2016-02-01 3:47 ` PGNet Dev 2016-02-01 10:30 ` Roger Pau Monné 2016-02-01 9:59 ` Wei Liu 2016-02-01 10:28 ` Roger Pau Monné 2 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-01 3:47 UTC (permalink / raw) To: xen-devel; +Cc: mukesh.rathor In any case, the !st issue, prior to any guest being launched, simply adding > @ GRUBG cfg > > - GRUB_CMDLINE_XEN=" ..." > + GRUB_CMDLINE_XEN=" dom0pvh ..." causes boot fail, ... (XEN) [2016-01-31 19:28:09] d0v0 EPT violation 0x1aa (-w-/r-x) gpa 0x000000f100054c mfn 0xf15 (XEN) [2016-01-31 19:28:09] d0v0 Walking EPT tables for GFN f1000: (XEN) [2016-01-31 19:28:09] d0v0 epte 8000000845108107 (XEN) [2016-01-31 19:28:09] d0v0 epte 800000085b680107 (XEN) [2016-01-31 19:28:09] d0v0 epte 8000000844af7107 (XEN) [2016-01-31 19:28:09] d0v0 epte 80500000f1000905 (XEN) [2016-01-31 19:28:09] d0v0 --- GLA 0xffffc900006a254c (XEN) [2016-01-31 19:28:09] domain_crash called from vmx.c:2685 (XEN) [2016-01-31 19:28:09] Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [2016-01-31 19:28:09] ----[ Xen-4.6.0_08-405 x86_64 debug=n Tainted: C ]---- (XEN) [2016-01-31 19:28:09] CPU: 0 (XEN) [2016-01-31 19:28:09] RIP: 0010:[<ffffffff8142a4ac>] (XEN) [2016-01-31 19:28:09] RFLAGS: 0000000000010246 CONTEXT: hvm guest (d0v0) (XEN) [2016-01-31 19:28:09] rax: 000000000000000d rbx: 00000000f100054c rcx: 000000009e9f (XEN) [2016-01-31 19:28:09] rdx: 0000000000000000 rsi: 0000000000000100 rdi: ffffffff81e0 (XEN) [2016-01-31 19:28:09] rbp: ffff880164b57908 rsp: ffff880164b578d8 r8: ffff88016d88 (XEN) [2016-01-31 19:28:09] r9: 0000000002400001 r10: 0000000000000000 r11: 000000000001 (XEN) [2016-01-31 19:28:09] r12: 0000000000000020 r13: ffff88016453aec0 r14: ffffc900006c (XEN) [2016-01-31 19:28:09] r15: ffff880164b57a20 cr0: 0000000080050033 cr4: 000000000000 (XEN) [2016-01-31 19:28:09] cr3: 0000000001e0b000 cr2: 0000000000000000 (XEN) [2016-01-31 19:28:09] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0010 (XEN) [2016-01-31 19:28:09] Guest stack trace from rsp=ffff880164b578d8: (XEN) [2016-01-31 19:28:09] Fault while accessing guest memory. (XEN) [2016-01-31 19:28:09] Hardware Dom0 crashed: rebooting machine in 5 seconds. ... Removing the dom0pvh gets me back up & running. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 3:47 ` PGNet Dev @ 2016-02-01 10:30 ` Roger Pau Monné 2016-02-01 12:16 ` PGNet Dev 0 siblings, 1 reply; 27+ messages in thread From: Roger Pau Monné @ 2016-02-01 10:30 UTC (permalink / raw) To: PGNet Dev, xen-devel; +Cc: Boris Ostrovsky El 01/02/16 a les 4.47, PGNet Dev ha escrit: > In any case, the !st issue, prior to any guest being launched, simply > adding > >> @ GRUBG cfg >> >> - GRUB_CMDLINE_XEN=" ..." >> + GRUB_CMDLINE_XEN=" dom0pvh ..." Does your kernel support PVH mode (ie: CONFIG_PVH enabled?) > causes boot fail, > > ... > (XEN) [2016-01-31 19:28:09] d0v0 EPT violation 0x1aa (-w-/r-x) gpa > 0x000000f100054c mfn 0xf15 > (XEN) [2016-01-31 19:28:09] d0v0 Walking EPT tables for GFN f1000: > (XEN) [2016-01-31 19:28:09] d0v0 epte 8000000845108107 > (XEN) [2016-01-31 19:28:09] d0v0 epte 800000085b680107 > (XEN) [2016-01-31 19:28:09] d0v0 epte 8000000844af7107 > (XEN) [2016-01-31 19:28:09] d0v0 epte 80500000f1000905 > (XEN) [2016-01-31 19:28:09] d0v0 --- GLA 0xffffc900006a254c > (XEN) [2016-01-31 19:28:09] domain_crash called from vmx.c:2685 > (XEN) [2016-01-31 19:28:09] Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) [2016-01-31 19:28:09] ----[ Xen-4.6.0_08-405 x86_64 debug=n > Tainted: C ]---- > (XEN) [2016-01-31 19:28:09] CPU: 0 > (XEN) [2016-01-31 19:28:09] RIP: 0010:[<ffffffff8142a4ac>] > (XEN) [2016-01-31 19:28:09] RFLAGS: 0000000000010246 CONTEXT: hvm > guest (d0v0) > (XEN) [2016-01-31 19:28:09] rax: 000000000000000d rbx: > 00000000f100054c rcx: 000000009e9f > (XEN) [2016-01-31 19:28:09] rdx: 0000000000000000 rsi: > 0000000000000100 rdi: ffffffff81e0 > (XEN) [2016-01-31 19:28:09] rbp: ffff880164b57908 rsp: > ffff880164b578d8 r8: ffff88016d88 > (XEN) [2016-01-31 19:28:09] r9: 0000000002400001 r10: > 0000000000000000 r11: 000000000001 > (XEN) [2016-01-31 19:28:09] r12: 0000000000000020 r13: > ffff88016453aec0 r14: ffffc900006c > (XEN) [2016-01-31 19:28:09] r15: ffff880164b57a20 cr0: > 0000000080050033 cr4: 000000000000 > (XEN) [2016-01-31 19:28:09] cr3: 0000000001e0b000 cr2: 0000000000000000 > (XEN) [2016-01-31 19:28:09] ds: 0000 es: 0000 fs: 0000 gs: 0000 > ss: 0000 cs: 0010 > (XEN) [2016-01-31 19:28:09] Guest stack trace from rsp=ffff880164b578d8: > (XEN) [2016-01-31 19:28:09] Fault while accessing guest memory. > (XEN) [2016-01-31 19:28:09] Hardware Dom0 crashed: rebooting machine in > 5 seconds. > ... > > Removing the dom0pvh gets me back up & running. You will have to post the full boot log (Xen + Linux), there's not enough information here to diagnose the issue. Roger. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 10:30 ` Roger Pau Monné @ 2016-02-01 12:16 ` PGNet Dev 0 siblings, 0 replies; 27+ messages in thread From: PGNet Dev @ 2016-02-01 12:16 UTC (permalink / raw) To: roger.pau, xen-devel; +Cc: boris.ostrovsky On 02/01/2016 02:30 AM, Roger Pau Monné wrote: > Does your kernel support PVH mode (ie: CONFIG_PVH enabled?) not CONFIG_PVH, but per http://wiki.xenproject.org/wiki/Linux_PVH egrep \ "CONFIG_HYPERVISOR_GUEST=|CONFIG_PARAVIRT=|CONFIG_PARAVIRT_GUEST=|CONFIG_PARAVIRT_SPINLOCKS=|CONFIG_XEN=|CONFIG_XEN_PVH=" \ /boot/config-4.4.0-8.g9f68b90-default CONFIG_HYPERVISOR_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_XEN=y CONFIG_XEN_PVH=y note, there's no 'CONFIG_PARAVIRT_GUEST=', which appears an outdated reqt, http://marc.info/?l=linux-pm&m=136862383726154&w=2 as CONFIG_PARAVIRT_GUEST was replaced with CONFIG_HYPERVISOR_GUEST > You will have to post the full boot log (Xen + Linux), there's not > enough information here to diagnose the issue. I'll get more detail posted. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-01-31 21:27 Clarifying PVH mode requirements PGNet Dev 2016-02-01 3:47 ` PGNet Dev @ 2016-02-01 9:59 ` Wei Liu 2016-02-01 12:23 ` PGNet Dev 2016-02-01 10:28 ` Roger Pau Monné 2 siblings, 1 reply; 27+ messages in thread From: Wei Liu @ 2016-02-01 9:59 UTC (permalink / raw) To: PGNet Dev; +Cc: mukesh.rathor, Roger Pau Monné, wei.liu2, xen-devel (Cc Roger) On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote: > I run Xen 4.6 Dom0 > > rpm -qa | egrep -i "kernel-default-4|xen-4" > kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 > xen-4.6.0_08-405.1.x86_64 > > My guests are currently HVM in PVHVM mode; I'm exploring PVH. > > IIUC, for 4.6, this doc > > http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt > AIUI that document is not very up to date. In the mean time. There is another document in the same directory called pvh.markdown that you can have a look. Wei. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 9:59 ` Wei Liu @ 2016-02-01 12:23 ` PGNet Dev 2016-02-01 12:29 ` Wei Liu 2016-02-01 12:29 ` Roger Pau Monné 0 siblings, 2 replies; 27+ messages in thread From: PGNet Dev @ 2016-02-01 12:23 UTC (permalink / raw) To: wei.liu2; +Cc: roger.pau, xen-devel On 02/01/2016 01:59 AM, Wei Liu wrote: > (Cc Roger) > > On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote: >> I run Xen 4.6 Dom0 >> >> rpm -qa | egrep -i "kernel-default-4|xen-4" >> kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 >> xen-4.6.0_08-405.1.x86_64 >> >> My guests are currently HVM in PVHVM mode; I'm exploring PVH. >> >> IIUC, for 4.6, this doc >> >> http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt >> > > AIUI that document is not very up to date. > > In the mean time. There is another document in the same directory called > pvh.markdown that you can have a look. There's no http://xenbits.xen.org/docs/4.6-testing/misc/pvh.markdown but there is, (1) http://xenbits.xen.org/docs/unstable/misc/pvh.html which also looks 'dusty' This looks more promising, (2) https://github.com/mirage/xen/blob/master/docs/misc/pvh.markdown That the one? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 12:23 ` PGNet Dev @ 2016-02-01 12:29 ` Wei Liu 2016-02-01 12:29 ` Roger Pau Monné 1 sibling, 0 replies; 27+ messages in thread From: Wei Liu @ 2016-02-01 12:29 UTC (permalink / raw) To: PGNet Dev; +Cc: roger.pau, wei.liu2, xen-devel On Mon, Feb 01, 2016 at 04:23:46AM -0800, PGNet Dev wrote: > On 02/01/2016 01:59 AM, Wei Liu wrote: > >(Cc Roger) > > > >On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote: > >>I run Xen 4.6 Dom0 > >> > >> rpm -qa | egrep -i "kernel-default-4|xen-4" > >> kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 > >> xen-4.6.0_08-405.1.x86_64 > >> > >>My guests are currently HVM in PVHVM mode; I'm exploring PVH. > >> > >>IIUC, for 4.6, this doc > >> > >> http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt > >> > > > >AIUI that document is not very up to date. > > > >In the mean time. There is another document in the same directory called > >pvh.markdown that you can have a look. > > There's no > > http://xenbits.xen.org/docs/4.6-testing/misc/pvh.markdown > > but there is, > > (1) http://xenbits.xen.org/docs/unstable/misc/pvh.html > > which also looks 'dusty' > > This looks more promising, > > (2) https://github.com/mirage/xen/blob/master/docs/misc/pvh.markdown > I think (1) http://xenbits.xen.org/docs/unstable/misc/pvh.html is generate from (2) https://github.com/mirage/xen/blob/master/docs/misc/pvh.markdown In any case, yes, I was referring to (2). Wei. > That the one? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 12:23 ` PGNet Dev 2016-02-01 12:29 ` Wei Liu @ 2016-02-01 12:29 ` Roger Pau Monné 2016-02-01 12:38 ` PGNet Dev 1 sibling, 1 reply; 27+ messages in thread From: Roger Pau Monné @ 2016-02-01 12:29 UTC (permalink / raw) To: PGNet Dev, wei.liu2; +Cc: xen-devel El 01/02/16 a les 13.23, PGNet Dev ha escrit: > On 02/01/2016 01:59 AM, Wei Liu wrote: > > (1) http://xenbits.xen.org/docs/unstable/misc/pvh.html > > which also looks 'dusty' > > This looks more promising, > > (2) https://github.com/mirage/xen/blob/master/docs/misc/pvh.markdown > > That the one? Hm, maybe you haven't realized, but the content in (1) and (2) it's exactly the same. They are just different renderings of the same original document, which resides at: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown And is the document that Wei was referring to. Roger. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 12:29 ` Roger Pau Monné @ 2016-02-01 12:38 ` PGNet Dev 2016-02-01 13:38 ` PGNet Dev 0 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-01 12:38 UTC (permalink / raw) To: roger.pau, wei.liu2; +Cc: xen-devel On 02/01/2016 04:29 AM, Roger Pau Monné wrote: > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown That's all sorted now, thanks. I'll get the dom0pvh issue logs posted. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 12:38 ` PGNet Dev @ 2016-02-01 13:38 ` PGNet Dev 2016-02-01 14:54 ` Boris Ostrovsky 0 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-01 13:38 UTC (permalink / raw) To: roger.pau, wei.liu2; +Cc: xen-devel > I'll get the dom0pvh issue logs posted. http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt " ... To boot 64bit dom0 in PVH mode, add dom0pvh to grub xen command line. ..." http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown no mention of dom0pvh ... http://wiki.xenproject.org/wiki/Linux_PVH "... and use on the Xen command line the dom0pvh=1 bootup parameter. ..." As per my OP, and the 1st document above, I'd added dom0pvh to the grub config. After re-grub2-mkconfig, and reboot -> crash Changing, per the wiki, to dom0pvh=1 unfortunately makes no difference. (It'll be useful to get those 3 docs consistent in usage). In any case, here's the serial output with debug on Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ... /EndEntire /EndEntire file path: file path: /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor (cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: /HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 ]]/HD(2,1000,96000,c5cc9661271ee648 ,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE) /File(\EFI\OPENSUSE)/File(xen-4.6.0_08-405.efi)/File(xen-4.6.0_08-405.efi)/EndEntire /EndEntire Xen 4.6.0_08-405 (c/s ) EFI loader Using configuration file 'xen-4.6.0_08-405.cfg' vmlinuz-4.4.0-8.g9f68b90-default: 0x000000008bf22000-0x000000008c507000 initrd-4.4.0-8.g9f68b90-default: 0x000000008afbc000-0x000000008bf21da8 0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x92a26018 0x0000:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1d018 0x0000:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fc018 __ __ _ _ __ ___ ___ ___ _ _ ___ ____ \ \/ /___ _ __ | || | / /_ / _ \ / _ \ ( _ ) | || | / _ \| ___| \ // _ \ '_ \ | || |_| '_ \| | | | | | | |/ _ \ __| || |_| | | |___ \ / \ __/ | | | |__ _| (_) | |_| | | |_| | (_) |__|__ _| |_| |___) | /_/\_\___|_| |_| |_|(_)___(_)___/___\___/ \___/ |_| \___/|____/ |_____| (XEN) Xen version 4.6.0_08-405 (abuild@suse.de) (gcc (SUSE Linux) 4.8.5) debug=n Wed Jan 27 15:23:26 UTC 2016 (XEN) Latest ChangeSet: (XEN) Console output is synchronous. (XEN) Bootloader: EFI (XEN) Command line: dom0pvh=1 dom0_mem=4096M,max:4096M dom0_max_vcpus=1 dom0_vcpus_pin=true cpuidle=1 cpufreq=xen clocksource=hpet iommu=verbose sched=credit vga=gfx-1920x1080x16 com1=1152 (XEN) Video information: (XEN) VGA is graphics mode 800x600, 32 bpp (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 6 EDD information structures (XEN) EFI RAM map: (XEN) 0000000000000000 - 0000000000008000 (reserved) (XEN) 0000000000008000 - 0000000000048000 (usable) (XEN) 0000000000048000 - 0000000000059000 (reserved) (XEN) 0000000000059000 - 000000000005f000 (usable) (XEN) 000000000005f000 - 00000000000a0000 (reserved) (XEN) 0000000000100000 - 000000008d93e000 (usable) (XEN) 000000008d93e000 - 000000008d945000 (ACPI NVS) (XEN) 000000008d945000 - 000000008e25a000 (reserved) (XEN) 000000008e25a000 - 000000008e260000 (usable) (XEN) 000000008e260000 - 000000008e6a1000 (reserved) (XEN) 000000008e6a1000 - 0000000091783000 (usable) (XEN) 0000000091783000 - 00000000919eb000 (reserved) (XEN) 00000000919eb000 - 0000000091a1e000 (usable) (XEN) 0000000091a1e000 - 0000000091a7b000 (reserved) (XEN) 0000000091a7b000 - 0000000091ae1000 (usable) (XEN) 0000000091ae1000 - 0000000091b87000 (reserved) (XEN) 0000000091b87000 - 0000000091bbb000 (usable) (XEN) 0000000091bbb000 - 0000000091bbc000 (reserved) (XEN) 0000000091bbc000 - 0000000091bbe000 (usable) (XEN) 0000000091bbe000 - 0000000091bbf000 (reserved) (XEN) 0000000091bbf000 - 0000000091bc7000 (usable) (XEN) 0000000091bc7000 - 0000000091bca000 (reserved) (XEN) 0000000091bca000 - 0000000091bdd000 (usable) (XEN) 0000000091bdd000 - 0000000091be8000 (reserved) (XEN) 0000000091be8000 - 0000000091c69000 (usable) (XEN) 0000000091c69000 - 0000000091ce6000 (reserved) (XEN) 0000000091ce6000 - 0000000091d30000 (usable) (XEN) 0000000091d30000 - 000000009208e000 (reserved) (XEN) 000000009208e000 - 00000000920d5000 (usable) (XEN) 00000000920d5000 - 000000009214b000 (reserved) (XEN) 000000009214b000 - 000000009217e000 (usable) (XEN) 000000009217e000 - 0000000092296000 (reserved) (XEN) 0000000092296000 - 00000000922b5000 (usable) (XEN) 00000000922b5000 - 0000000092359000 (reserved) (XEN) 0000000092359000 - 0000000092363000 (usable) (XEN) 0000000092363000 - 0000000092462000 (reserved) (XEN) 0000000092462000 - 0000000092467000 (usable) (XEN) 0000000092467000 - 00000000925b6000 (reserved) (XEN) 00000000925b6000 - 00000000925b8000 (usable) (XEN) 00000000925b8000 - 00000000925be000 (reserved) (XEN) 00000000925be000 - 00000000925c0000 (usable) (XEN) 00000000925c0000 - 00000000925c6000 (reserved) (XEN) 00000000925c6000 - 00000000925c8000 (usable) (XEN) 00000000925c8000 - 00000000925cf000 (reserved) (XEN) 00000000925cf000 - 00000000925d2000 (usable) (XEN) 00000000925d2000 - 00000000925e5000 (reserved) (XEN) 00000000925e5000 - 00000000925e8000 (usable) (XEN) 00000000925e8000 - 00000000925eb000 (reserved) (XEN) 00000000925eb000 - 00000000925ee000 (usable) (XEN) 00000000925ee000 - 0000000092825000 (reserved) (XEN) 0000000092825000 - 0000000092827000 (usable) (XEN) 0000000092827000 - 0000000092861000 (reserved) (XEN) 0000000092861000 - 0000000092863000 (usable) (XEN) 0000000092863000 - 000000009286b000 (reserved) (XEN) 000000009286b000 - 000000009286d000 (usable) (XEN) 000000009286d000 - 0000000092873000 (reserved) (XEN) 0000000092873000 - 0000000092875000 (usable) (XEN) 0000000092875000 - 000000009287d000 (reserved) (XEN) 000000009287d000 - 000000009287e000 (usable) (XEN) 000000009287e000 - 000000009e1a0000 (reserved) (XEN) 000000009e1a0000 - 000000009e430000 (usable) (XEN) 000000009e430000 - 000000009e845000 (reserved) (XEN) 000000009e845000 - 000000009e891000 (usable) (XEN) 000000009e891000 - 000000009e9c5000 (ACPI NVS) (XEN) 000000009e9c5000 - 000000009f000000 (reserved) (XEN) 00000000f0000000 - 00000000f8000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fed00000 - 00000000fed04000 (reserved) (XEN) 00000000fed1c000 - 00000000fed20000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ff000000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000085e000000 (usable) (XEN) ACPI: RSDP 9E995000, 0024 (r2 SUPERM) (XEN) ACPI: XSDT 9E995090, 009C (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FACP 9E9A32E8, 010C (r5 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: DSDT 9E9951C0, E121 (r2 SUPERM SMCI--MB 0 INTL 20120711) (XEN) ACPI: FACS 9E9C4F80, 0040 (XEN) ACPI: APIC 9E9A33F8, 0072 (r3 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FPDT 9E9A3470, 0044 (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FIDT 9E9A34B8, 009C (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: SSDT 9E9A3558, 0C7D (r2 Ther_R Ther_Rvp 1000 INTL 20120711) (XEN) ACPI: SSDT 9E9A41D8, 0539 (r2 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT 9E9A4718, 0B74 (r2 CpuRef CpuSsdt 3000 INTL 20051117) (XEN) ACPI: SSDT 9E9A5290, 02DE (r2 PmRef Cpu0Tst 3000 INTL 20051117) (XEN) ACPI: SSDT 9E9A5570, 0348 (r2 PmRef ApTst 3000 INTL 20051117) (XEN) ACPI: MCFG 9E9A58B8, 003C (r1 SUPERM SMCI--MB 1072009 MSFT 97) (XEN) ACPI: HPET 9E9A58F8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5) (XEN) ACPI: SSDT 9E9A5930, 0397 (r1 SataRe SataTabl 1000 INTL 20120711) (XEN) ACPI: SSDT 9E9A5CC8, 57F6 (r2 SaSsdt SaSsdt 3000 INTL 20120711) (XEN) ACPI: ASF! 9E9AB4C0, 00A5 (r32 INTEL HCG 1 TFSM F4240) (XEN) ACPI: DMAR 9E9AB568, 0080 (r1 INTEL BDW 1 INTL 1) (XEN) System RAM: 32494MB (33274612kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000085e000000 (XEN) Domain heap initialised (XEN) Allocated console ring of 64 KiB. (XEN) vesafb: framebuffer at 0xd1000000, mapped to 0xffff82c000201000, using 1920k, total 1920k (XEN) vesafb: mode is 800x600x32, linelength=3200, font 8x8 (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 (XEN) SMBIOS 2.7 present. (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1808 (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 9e9c4f80/0000000000000000, using 32 (XEN) ACPI: wakeup_vec[9e9c4f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) Processor #0 7:12 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 7:12 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) Processor #4 7:12 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) Processor #6 7:12 APIC version 21 (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 8, 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 4 CPUs (0 hotplug CPUs) (XEN) NR_CPUS:1024 nr_cpumask_bits:64 (XEN) mapped APIC to ffff82cfff7fb000 (fee00000) (XEN) mapped IOAPIC to ffff82cfff7fa000 (fec00000) (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X (XEN) Not enabling x2APIC (upon firmware request) (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) Intel machine check reporting enabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3092.931 MHz processor. (XEN) EFI memory map: (mapping BootServices) (XEN) 0000000000000-0000000007fff type=3 attr=000000000000000f (XEN) 0000000008000-0000000047fff type=7 attr=000000000000000f (XEN) 0000000048000-0000000057fff type=4 attr=000000000000000f (XEN) 0000000058000-0000000058fff type=0 attr=000000000000000f (XEN) 0000000059000-000000005bfff type=7 attr=000000000000000f (XEN) 000000005c000-000000005efff type=2 attr=000000000000000f (XEN) 000000005f000-000000005ffff type=4 attr=000000000000000f (XEN) 0000000060000-000000009efff type=3 attr=000000000000000f (XEN) 000000009f000-000000009ffff type=0 attr=000000000000000f (XEN) 0000000100000-000006635cfff type=7 attr=000000000000000f (XEN) 000006635d000-000008a7b0fff type=2 attr=000000000000000f (XEN) 000008a7b1000-000008afbbfff type=7 attr=000000000000000f (XEN) 000008afbc000-000008c506fff type=2 attr=000000000000000f (XEN) 000008c507000-000008d93dfff type=1 attr=000000000000000f (XEN) 000008d93e000-000008d944fff type=10 attr=000000000000000f (XEN) 000008d945000-000008da98fff type=4 attr=000000000000000f (XEN) 000008da99000-000008e255fff type=3 attr=000000000000000f (XEN) 000008e256000-000008e259fff type=4 attr=000000000000000f (XEN) 000008e25a000-000008e25ffff type=7 attr=000000000000000f (XEN) 000008e260000-000008e264fff type=4 attr=000000000000000f (XEN) 000008e265000-000008e26efff type=3 attr=000000000000000f (XEN) 000008e26f000-000008e275fff type=4 attr=000000000000000f (XEN) 000008e276000-000008e27ffff type=3 attr=000000000000000f (XEN) 000008e280000-000008e28afff type=4 attr=000000000000000f (XEN) 000008e28b000-000008e691fff type=6 attr=800000000000000f (XEN) 000008e692000-000008e6a0fff type=4 attr=000000000000000f (XEN) 000008e6a1000-000008e6aefff type=7 attr=000000000000000f (XEN) 000008e6af000-000008e6affff type=2 attr=000000000000000f (XEN) 000008e6b0000-0000091782fff type=7 attr=000000000000000f (XEN) 0000091783000-00000919eafff type=4 attr=000000000000000f (XEN) 00000919eb000-0000091a1dfff type=7 attr=000000000000000f (XEN) 0000091a1e000-0000091a7afff type=4 attr=000000000000000f (XEN) 0000091a7b000-0000091ae0fff type=7 attr=000000000000000f (XEN) 0000091ae1000-0000091b86fff type=4 attr=000000000000000f (XEN) 0000091b87000-0000091bbafff type=7 attr=000000000000000f (XEN) 0000091bbb000-0000091bbbfff type=4 attr=000000000000000f (XEN) 0000091bbc000-0000091bbdfff type=7 attr=000000000000000f (XEN) 0000091bbe000-0000091bbefff type=4 attr=000000000000000f (XEN) 0000091bbf000-0000091bc6fff type=7 attr=000000000000000f (XEN) 0000091bc7000-0000091bc9fff type=4 attr=000000000000000f (XEN) 0000091bca000-0000091bdcfff type=7 attr=000000000000000f (XEN) 0000091bdd000-0000091be7fff type=4 attr=000000000000000f (XEN) 0000091be8000-0000091c68fff type=7 attr=000000000000000f (XEN) 0000091c69000-0000091ce5fff type=4 attr=000000000000000f (XEN) 0000091ce6000-0000091d2ffff type=7 attr=000000000000000f (XEN) 0000091d30000-000009208dfff type=4 attr=000000000000000f (XEN) 000009208e000-00000920d4fff type=7 attr=000000000000000f (XEN) 00000920d5000-000009214afff type=4 attr=000000000000000f (XEN) 000009214b000-000009217dfff type=7 attr=000000000000000f (XEN) 000009217e000-0000092295fff type=4 attr=000000000000000f (XEN) 0000092296000-00000922b4fff type=7 attr=000000000000000f (XEN) 00000922b5000-0000092358fff type=4 attr=000000000000000f (XEN) 0000092359000-0000092362fff type=7 attr=000000000000000f (XEN) 0000092363000-0000092461fff type=4 attr=000000000000000f (XEN) 0000092462000-0000092466fff type=7 attr=000000000000000f (XEN) 0000092467000-00000925b5fff type=4 attr=000000000000000f (XEN) 00000925b6000-00000925b7fff type=7 attr=000000000000000f (XEN) 00000925b8000-00000925bdfff type=4 attr=000000000000000f (XEN) 00000925be000-00000925bffff type=7 attr=000000000000000f (XEN) 00000925c0000-00000925c5fff type=4 attr=000000000000000f (XEN) 00000925c6000-00000925c7fff type=7 attr=000000000000000f (XEN) 00000925c8000-00000925cefff type=4 attr=000000000000000f (XEN) 00000925cf000-00000925d1fff type=7 attr=000000000000000f (XEN) 00000925d2000-00000925e4fff type=4 attr=000000000000000f (XEN) 00000925e5000-00000925e7fff type=7 attr=000000000000000f (XEN) 00000925e8000-00000925eafff type=4 attr=000000000000000f (XEN) 00000925eb000-00000925edfff type=7 attr=000000000000000f (XEN) 00000925ee000-0000092824fff type=4 attr=000000000000000f (XEN) 0000092825000-0000092826fff type=7 attr=000000000000000f (XEN) 0000092827000-0000092860fff type=4 attr=000000000000000f (XEN) 0000092861000-0000092862fff type=7 attr=000000000000000f (XEN) 0000092863000-000009286afff type=4 attr=000000000000000f (XEN) 000009286b000-000009286cfff type=7 attr=000000000000000f (XEN) 000009286d000-0000092872fff type=4 attr=000000000000000f (XEN) 0000092873000-0000092874fff type=7 attr=000000000000000f (XEN) 0000092875000-000009287cfff type=4 attr=000000000000000f (XEN) 000009287d000-000009287dfff type=7 attr=000000000000000f (XEN) 000009287e000-000009e19ffff type=4 attr=000000000000000f (XEN) 000009e1a0000-000009e42ffff type=7 attr=000000000000000f (XEN) 000009e430000-000009e79ffff type=3 attr=000000000000000f (XEN) 000009e7a0000-000009e7e9fff type=0 attr=000000000000000f (XEN) 000009e7ea000-000009e844fff type=0 attr=000000000000000f (XEN) 000009e845000-000009e890fff type=7 attr=000000000000000f (XEN) 000009e891000-000009e9affff type=10 attr=000000000000000f (XEN) 000009e9b0000-000009e9c0fff type=10 attr=000000000000000f (XEN) 000009e9c1000-000009e9c4fff type=10 attr=000000000000000f (XEN) 000009e9c5000-000009eabffff type=6 attr=800000000000000f (XEN) 000009eac0000-000009ec3bfff type=6 attr=800000000000000f (XEN) 000009ec3c000-000009ec3dfff type=6 attr=800000000000000f (XEN) 000009ec3e000-000009eef0fff type=6 attr=800000000000000f (XEN) 000009eef1000-000009eef2fff type=6 attr=800000000000000f (XEN) 000009eef3000-000009ef8efff type=6 attr=800000000000000f (XEN) 000009ef8f000-000009efa6fff type=5 attr=800000000000000f (XEN) 000009efa7000-000009effefff type=5 attr=800000000000000f (XEN) 000009efff000-000009effffff type=4 attr=000000000000000f (XEN) 0000100000000-000085dffffff type=7 attr=000000000000000f (XEN) 00000f0000000-00000f7ffffff type=11 attr=8000000000000001 (XEN) 00000fec00000-00000fec00fff type=11 attr=8000000000000001 (XEN) 00000fed00000-00000fed03fff type=11 attr=8000000000000001 (XEN) 00000fed1c000-00000fed1ffff type=11 attr=8000000000000001 (XEN) 00000fee00000-00000fee00fff type=11 attr=8000000000000001 (XEN) 00000ff000000-00000ffffffff type=11 attr=8000000000000001 (XEN) Initing memory sharing. (XEN) alt table ffff82d0802d3450 -> ffff82d0802d4854 (XEN) spurious 8259A interrupt: IRQ7. (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 7f (XEN) PCI: MCFG area at f0000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-7f (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB. (XEN) Intel VT-d Snoop Control 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 enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Suppress EOI broadcast on CPU#0 (XEN) enabled ExtINT on CPU#0 (XEN) ENABLING IO-APIC IRQs (XEN) init IO_APIC IRQs (XEN) IO-APIC (apicid-pin) 8-0, 8-16, 8-17, 8-18, 8-19, 8-20, 8-21, 8-22, 8-23 not connected. (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=0 pin2=0 (XEN) number of MP IRQ sources: 15. (XEN) number of IO-APIC #8 registers: 24. (XEN) testing the IO APIC....................... (XEN) IO APIC #8...... (XEN) .... register #00: 08000000 (XEN) ....... : physical APIC id: 08 (XEN) ....... : Delivery Type: 0 (XEN) ....... : LTS : 0 (XEN) .... register #01: 00170020 (XEN) ....... : max redirection entries: 0017 (XEN) ....... : PRQ implemented: 0 (XEN) ....... : IO APIC version: 0020 (XEN) .... IRQ redirection table: (XEN) NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: (XEN) 00 000 00 1 0 0 0 0 0 7 00 (XEN) 01 001 01 0 0 0 0 0 1 1 30 (XEN) 02 001 01 0 0 0 0 0 1 1 F0 (XEN) 03 001 01 0 0 0 0 0 1 1 38 (XEN) 04 001 01 0 0 0 0 0 1 1 F1 (XEN) 05 001 01 0 0 0 0 0 1 1 40 (XEN) 06 001 01 0 0 0 0 0 1 1 48 (XEN) 07 001 01 0 0 0 0 0 1 1 50 (XEN) 08 001 01 0 0 0 0 0 1 1 58 (XEN) 09 001 01 1 1 0 0 0 1 1 60 (XEN) 0a 001 01 0 0 0 0 0 1 1 68 (XEN) 0b 001 01 0 0 0 0 0 1 1 70 (XEN) 0c 001 01 0 0 0 0 0 1 1 78 (XEN) 0d 001 01 0 0 0 0 0 1 1 88 (XEN) 0e 001 01 0 0 0 0 0 1 1 90 (XEN) 0f 001 01 0 0 0 0 0 1 1 98 (XEN) 10 000 00 1 0 0 0 0 0 0 00 (XEN) 11 000 00 1 0 0 0 0 0 0 00 (XEN) 12 000 00 1 0 0 0 0 0 0 00 (XEN) 13 000 00 1 0 0 0 0 0 0 00 (XEN) 14 000 00 1 0 0 0 0 0 0 00 (XEN) 15 000 00 1 0 0 0 0 0 0 00 (XEN) 16 000 00 1 0 0 0 0 0 0 00 (XEN) 17 000 00 1 0 0 0 0 0 0 00 (XEN) Using vector-based indexing (XEN) IRQ to pin mappings: (XEN) IRQ240 -> 0:2 (XEN) IRQ48 -> 0:1 (XEN) IRQ56 -> 0:3 (XEN) IRQ241 -> 0:4 (XEN) IRQ64 -> 0:5 (XEN) IRQ72 -> 0:6 (XEN) IRQ80 -> 0:7 (XEN) IRQ88 -> 0:8 (XEN) IRQ96 -> 0:9 (XEN) IRQ104 -> 0:10 (XEN) IRQ112 -> 0:11 (XEN) IRQ120 -> 0:12 (XEN) IRQ136 -> 0:13 (XEN) IRQ144 -> 0:14 (XEN) IRQ152 -> 0:15 (XEN) .................................... done. (XEN) Using local APIC timer interrupts. (XEN) calibrating APIC timer ... (XEN) ..... CPU clock speed is 3092.9244 MHz. (XEN) ..... host bus clock speed is 99.7717 MHz. (XEN) ..... bus_scale = 0x662c (XEN) TSC deadline timer enabled (XEN) [2016-02-01 05:28:23] Platform timer is 14.318MHz HPET (XEN) [2016-02-01 05:28:23] mwait-idle: MWAIT substates: 0x42120 (XEN) [2016-02-01 05:28:23] mwait-idle: v0.4 model 0x3c (XEN) [2016-02-01 05:28:23] mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) [2016-02-01 05:28:23] VMX: Supported advanced features: (XEN) [2016-02-01 05:28:23] - APIC MMIO access virtualisation (XEN) [2016-02-01 05:28:23] - APIC TPR shadow (XEN) [2016-02-01 05:28:23] - Extended Page Tables (EPT) (XEN) [2016-02-01 05:28:23] - Virtual-Processor Identifiers (VPID) (XEN) [2016-02-01 05:28:23] - Virtual NMI (XEN) [2016-02-01 05:28:23] - MSR direct-access bitmap (XEN) [2016-02-01 05:28:23] - Unrestricted Guest (XEN) [2016-02-01 05:28:23] - VMCS shadowing (XEN) [2016-02-01 05:28:23] - VM Functions (XEN) [2016-02-01 05:28:23] HVM: ASIDs enabled. (XEN) [2016-02-01 05:28:23] HVM: VMX enabled (XEN) [2016-02-01 05:28:23] HVM: Hardware Assisted Paging (HAP) detected (XEN) [2016-02-01 05:28:23] HVM: HAP page sizes: 4kB, 2MB, 1GB (XEN) [2016-02-01 05:28:23] Suppress EOI broadcast on CPU#1 (XEN) [2016-02-01 05:28:23] masked ExtINT on CPU#1 (XEN) [2016-02-01 05:28:23] [VT-D]INTR-REMAP: Request device [0000:f0:1f.0] fault index 0, iommu reg = ffff82c0003e2000 (XEN) [2016-02-01 05:28:23] [VT-D]INTR-REMAP: reason 22 - Present field in the IRTE entry is clear (XEN) [2016-02-01 05:28:23] Suppress EOI broadcast on CPU#2 (XEN) [2016-02-01 05:28:23] masked ExtINT on CPU#2 (XEN) [2016-02-01 05:28:23] Suppress EOI broadcast on CPU#3 (XEN) [2016-02-01 05:28:23] masked ExtINT on CPU#3 (XEN) [2016-02-01 05:28:23] Brought up 4 CPUs (XEN) [2016-02-01 05:28:23] ACPI sleep modes: S3 (XEN) [2016-02-01 05:28:23] VPMU: disabled (XEN) [2016-02-01 05:28:23] mcheck_poll: Machine check polling timer started. (XEN) [2016-02-01 05:28:23] Dom0 has maximum 216 PIRQs (XEN) [2016-02-01 05:28:23] NX (Execute Disable) protection active (XEN) [2016-02-01 05:28:23] *** LOADING DOMAIN 0 *** (XEN) [2016-02-01 05:28:23] Xen kernel: 64-bit, lsb, compat32 (XEN) [2016-02-01 05:28:23] Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2265000 (XEN) [2016-02-01 05:28:23] PHYSICAL MEMORY ARRANGEMENT: (XEN) [2016-02-01 05:28:23] Dom0 alloc.: 0000000840000000->0000000844000000 (1028250 pages to be allocated) (XEN) [2016-02-01 05:28:23] Init. ramdisk: 000000085d09a000->000000085dfffda8 (XEN) [2016-02-01 05:28:23] VIRTUAL MEMORY ARRANGEMENT: (XEN) [2016-02-01 05:28:23] Loaded kernel: ffffffff81000000->ffffffff82265000 (XEN) [2016-02-01 05:28:23] Init. ramdisk: 0000000000000000->0000000000000000 (XEN) [2016-02-01 05:28:23] Phys-Mach map: 0000008000000000->0000008000800000 (XEN) [2016-02-01 05:28:23] Start info: ffffffff82265000->ffffffff822664b4 (XEN) [2016-02-01 05:28:23] Page tables: ffffffff82267000->ffffffff8227c000 (XEN) [2016-02-01 05:28:24] Boot stack: ffffffff8227c000->ffffffff8227d000 (XEN) [2016-02-01 05:28:24] TOTAL: ffffffff80000000->ffffffff82400000 (XEN) [2016-02-01 05:28:24] ENTRY ADDRESS: ffffffff81f3b1f0 (XEN) [2016-02-01 05:28:24] Dom0 has maximum 1 VCPUs (XEN) [2016-02-01 05:28:24] Bogus DMIBAR 0xfed18001 on 0000:00:00.0 (XEN) [2016-02-01 05:28:24] Scrubbing Free RAM on 1 nodes using 4 CPUs (XEN) [2016-02-01 05:28:24] ...................................................................done. (XEN) [2016-02-01 05:28:25] Initial low memory virq threshold set at 0x4000 pages. (XEN) [2016-02-01 05:28:25] Std. Loglevel: All (XEN) [2016-02-01 05:28:25] Guest Loglevel: All (XEN) [2016-02-01 05:28:25] ********************************************** (XEN) [2016-02-01 05:28:25] ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) [2016-02-01 05:28:25] ******* This option is intended to aid debugging of Xen by ensuring (XEN) [2016-02-01 05:28:26] ******* that all output is synchronously delivered on the serial line. (XEN) [2016-02-01 05:28:26] ******* However it can introduce SIGNIFICANT latencies and affect (XEN) [2016-02-01 05:28:26] ******* timekeeping. It is NOT recommended for production use! (XEN) [2016-02-01 05:28:26] ********************************************** (XEN) [2016-02-01 05:28:26] 3... 2... 1... (XEN) [2016-02-01 05:28:29] Xen is relinquishing VGA console. (XEN) [2016-02-01 05:28:29] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) [2016-02-01 05:28:29] Freed 324kB init memory. mapping kernel into physical memory about to get started... [ 0.000000] Linux version 4.4.0-8.g9f68b90-default (geeko@buildhost) (gcc version 5.2.1 20151008 [gcc-5-branch revision 228597] (SUSE Linux) ) #1 SMP PREEMPT Thu Jan 28 08:15:06 UTC 201) [ 0.000000] efi: EFI_MEMMAP is not enabled. [ 0.000000] esrt: ESRT header is not in the memory map. [ 0.000000] ACPI: RSDP 0x000000009E995000 000024 (v02 SUPERM) [ 0.000000] ACPI: XSDT 0x000000009E995090 00009C (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: FACP 0x000000009E9A32E8 00010C (v05 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: DSDT 0x000000009E9951C0 00E121 (v02 SUPERM SMCI--MB 00000000 INTL 20120711) [ 0.000000] ACPI: FACS 0x000000009E9C4F80 000040 [ 0.000000] ACPI: APIC 0x000000009E9A33F8 000072 (v03 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: FPDT 0x000000009E9A3470 000044 (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: FIDT 0x000000009E9A34B8 00009C (v01 SUPERM SMCI--MB 01072009 AMI 00010013) [ 0.000000] ACPI: SSDT 0x000000009E9A3558 000C7D (v02 Ther_R Ther_Rvp 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x000000009E9A41D8 000539 (v02 PmRef Cpu0Ist 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9A4718 000B74 (v02 CpuRef CpuSsdt 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9A5290 0002DE (v02 PmRef Cpu0Tst 00003000 INTL 20051117) [ 0.000000] ACPI: SSDT 0x000000009E9A5570 000348 (v02 PmRef ApTst 00003000 INTL 20051117) [ 0.000000] ACPI: MCFG 0x000000009E9A58B8 00003C (v01 SUPERM SMCI--MB 01072009 MSFT 00000097) [ 0.000000] ACPI: HPET 0x000000009E9A58F8 000038 (v01 SUPERM SMCI--MB 01072009 AMI. 00000005) [ 0.000000] ACPI: SSDT 0x000000009E9A5930 000397 (v01 SataRe SataTabl 00001000 INTL 20120711) [ 0.000000] ACPI: SSDT 0x000000009E9A5CC8 0057F6 (v02 SaSsdt SaSsdt 00003000 INTL 20120711) [ 0.000000] ACPI: ASF! 0x000000009E9AB4C0 0000A5 (v32 INTEL HCG 00000001 TFSM 000F4240) [ 0.000000] ACPI: RMAD 0x000000009E9AB568 000080 (v01 INTEL BDW 00000001 INTL 00000001) [ 0.000000] Kernel command line: root=UUID=4716053b-39da-4cc1-a7ce-72171b862357 dolvm lvmwait=/dev/mapper/VG_XSVR-LV_ROOT rootfstype=ext4 rootflags=journal_checksum noresume showopts n [ 64.025526] ACPI: 8 ACPI AML tables successfully acquired and loaded [ 64.033141] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 64.039302] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 64.077354] cpu 0 spinlock event irq 25 [ 64.081192] Could not initialize VPMU for cpu 0, error -95 [ 64.111232] NMI watchdog: disabled (cpu0): hardware events not enabled [ 64.126228] Grant table initialized [ 64.162645] ACPI: Executed 6 blocks of module-level executable AML code (XEN) [2016-02-01 05:28:29] d0v0 EPT violation 0x1aa (-w-/r-x) gpa 0x000000f100054c mfn 0xf1000 type 5 (XEN) [2016-02-01 05:28:29] d0v0 Walking EPT tables for GFN f1000: (XEN) [2016-02-01 05:28:29] d0v0 epte 800000084510c107 (XEN) [2016-02-01 05:28:29] d0v0 epte 800000085b684107 (XEN) [2016-02-01 05:28:29] d0v0 epte 8000000844afb107 (XEN) [2016-02-01 05:28:29] d0v0 epte 80500000f1000905 (XEN) [2016-02-01 05:28:29] d0v0 --- GLA 0xffffc900006a254c (XEN) [2016-02-01 05:28:29] domain_crash called from vmx.c:2685 (XEN) [2016-02-01 05:28:29] Domain 0 (vcpu#0) crashed on cpu#0: (XEN) [2016-02-01 05:28:29] ----[ Xen-4.6.0_08-405 x86_64 debug=n Tainted: C ]---- (XEN) [2016-02-01 05:28:29] CPU: 0 (XEN) [2016-02-01 05:28:29] RIP: 0010:[<ffffffff8142a4ac>] (XEN) [2016-02-01 05:28:29] RFLAGS: 0000000000010246 CONTEXT: hvm guest (d0v0) (XEN) [2016-02-01 05:28:29] rax: 000000000000000d rbx: 00000000f100054c rcx: 000000009e9c4fff (XEN) [2016-02-01 05:28:29] rdx: 0000000000000000 rsi: 0000000000000100 rdi: ffffffff81eaedc0 (XEN) [2016-02-01 05:28:29] rbp: ffff880164b57908 rsp: ffff880164b578d8 r8: ffff88016d8c7458 (XEN) [2016-02-01 05:28:29] r9: 0000000002400001 r10: 0000000000000000 r11: 0000000000002001 (XEN) [2016-02-01 05:28:29] r12: 0000000000000020 r13: ffff88016453aec0 r14: ffffc900006a254c (XEN) [2016-02-01 05:28:29] r15: ffff880164b57a20 cr0: 0000000080050033 cr4: 00000000000406b0 (XEN) [2016-02-01 05:28:29] cr3: 0000000001e0b000 cr2: 0000000000000000 (XEN) [2016-02-01 05:28:29] ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0010 (XEN) [2016-02-01 05:28:29] Guest stack trace from rsp=ffff880164b578d8: (XEN) [2016-02-01 05:28:29] Fault while accessing guest memory. (XEN) [2016-02-01 05:28:29] Hardware Dom0 crashed: rebooting machine in 5 seconds. then the system simply reboots/repeats. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 13:38 ` PGNet Dev @ 2016-02-01 14:54 ` Boris Ostrovsky 2016-02-01 16:56 ` Jan Beulich 2016-02-02 15:51 ` Jan Beulich 0 siblings, 2 replies; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-01 14:54 UTC (permalink / raw) To: PGNet Dev, roger.pau, wei.liu2; +Cc: Jan Beulich, xen-devel On 02/01/2016 08:38 AM, PGNet Dev wrote: > > Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default > ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ... > > /EndEntire > /EndEntire > file path: file path: > /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor > (cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: > /HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 > ]]/HD(2,1000,96000,c5cc9661271ee648 > ,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE) > /File(\EFI\OPENSUSE)/File(xen-4.6.0_08-405.efi)/File(xen-4.6.0_08-405.efi)/EndEntire > > /EndEntire > Xen 4.6.0_08-405 (c/s ) EFI loader > Using configuration file 'xen-4.6.0_08-405.cfg' > vmlinuz-4.4.0-8.g9f68b90-default: 0x000000008bf22000-0x000000008c507000 > initrd-4.4.0-8.g9f68b90-default: 0x000000008afbc000-0x000000008bf21da8 > 0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x92a26018 > 0x0000:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1d018 > 0x0000:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fc018 > __ __ _ _ __ ___ ___ ___ _ _ ___ ____ > \ \/ /___ _ __ | || | / /_ / _ \ / _ \ ( _ ) | || | / _ \| ___| > \ // _ \ '_ \ | || |_| '_ \| | | | | | | |/ _ \ __| || |_| | | |___ \ > / \ __/ | | | |__ _| (_) | |_| | | |_| | (_) |__|__ _| |_| > |___) | > /_/\_\___|_| |_| |_|(_)___(_)___/___\___/ \___/ |_| \___/|____/ > |_____| > (XEN) Xen version 4.6.0_08-405 (abuild@suse.de) (gcc (SUSE Linux) > 4.8.5) debug=n Wed Jan 27 15:23:26 UTC 2016 > .... > (XEN) [2016-02-01 05:28:29] d0v0 EPT violation 0x1aa (-w-/r-x) gpa > 0x000000f100054c mfn 0xf1000 type 5 > (XEN) [2016-02-01 05:28:29] d0v0 Walking EPT tables for GFN f1000: > (XEN) [2016-02-01 05:28:29] d0v0 epte 800000084510c107 > (XEN) [2016-02-01 05:28:29] d0v0 epte 800000085b684107 > (XEN) [2016-02-01 05:28:29] d0v0 epte 8000000844afb107 > (XEN) [2016-02-01 05:28:29] d0v0 epte 80500000f1000905 > (XEN) [2016-02-01 05:28:29] d0v0 --- GLA 0xffffc900006a254c > (XEN) [2016-02-01 05:28:29] domain_crash called from vmx.c:2685 > (XEN) [2016-02-01 05:28:29] Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) [2016-02-01 05:28:29] ----[ Xen-4.6.0_08-405 x86_64 debug=n > Tainted: C ]---- > (XEN) [2016-02-01 05:28:29] CPU: 0 > (XEN) [2016-02-01 05:28:29] RIP: 0010:[<ffffffff8142a4ac>] > (XEN) [2016-02-01 05:28:29] RFLAGS: 0000000000010246 CONTEXT: hvm > guest (d0v0) > (XEN) [2016-02-01 05:28:29] rax: 000000000000000d rbx: > 00000000f100054c rcx: 000000009e9c4fff > (XEN) [2016-02-01 05:28:29] rdx: 0000000000000000 rsi: > 0000000000000100 rdi: ffffffff81eaedc0 > (XEN) [2016-02-01 05:28:29] rbp: ffff880164b57908 rsp: > ffff880164b578d8 r8: ffff88016d8c7458 > (XEN) [2016-02-01 05:28:29] r9: 0000000002400001 r10: > 0000000000000000 r11: 0000000000002001 > (XEN) [2016-02-01 05:28:29] r12: 0000000000000020 r13: > ffff88016453aec0 r14: ffffc900006a254c > (XEN) [2016-02-01 05:28:29] r15: ffff880164b57a20 cr0: > 0000000080050033 cr4: 00000000000406b0 > (XEN) [2016-02-01 05:28:29] cr3: 0000000001e0b000 cr2: 0000000000000000 > (XEN) [2016-02-01 05:28:29] ds: 0000 es: 0000 fs: 0000 gs: 0000 > ss: 0000 cs: 0010 > (XEN) [2016-02-01 05:28:29] Guest stack trace from rsp=ffff880164b578d8: > (XEN) [2016-02-01 05:28:29] Fault while accessing guest memory. > (XEN) [2016-02-01 05:28:29] Hardware Dom0 crashed: rebooting machine > in 5 seconds. (+Jan) This looks very much like it needs backport of 33c19df9a ("x86/PCI: intercept accesses to RO MMIO from dom0s in HVM containers") from unstable, which fixes PVH regression introduced by 9256f66c1606 ("x86/PCI: intercept all PV Dom0 MMCFG writes") -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 14:54 ` Boris Ostrovsky @ 2016-02-01 16:56 ` Jan Beulich 2016-02-01 19:17 ` Boris Ostrovsky 2016-02-02 15:51 ` Jan Beulich 1 sibling, 1 reply; 27+ messages in thread From: Jan Beulich @ 2016-02-01 16:56 UTC (permalink / raw) To: Boris Ostrovsky; +Cc: xen-devel, PGNet Dev, wei.liu2, roger.pau >>> On 01.02.16 at 15:54, <boris.ostrovsky@oracle.com> wrote: > On 02/01/2016 08:38 AM, PGNet Dev wrote: >> >> Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default >> ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ... >> >> /EndEntire >> /EndEntire >> file path: file path: >> > /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0, > 1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor >> (cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: >> /HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 >> ]]/HD(2,1000,96000,c5cc9661271ee648 >> ,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE) >> > /File(\EFI\OPENSUSE)/File(xen-4.6.0_08-405.efi)/File(xen-4.6.0_08-405.efi)/EndEnt > ire >> >> /EndEntire >> Xen 4.6.0_08-405 (c/s ) EFI loader >> Using configuration file 'xen-4.6.0_08-405.cfg' >> vmlinuz-4.4.0-8.g9f68b90-default: 0x000000008bf22000-0x000000008c507000 >> initrd-4.4.0-8.g9f68b90-default: 0x000000008afbc000-0x000000008bf21da8 >> 0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x92a26018 >> 0x0000:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1d018 >> 0x0000:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fc018 >> __ __ _ _ __ ___ ___ ___ _ _ ___ ____ >> \ \/ /___ _ __ | || | / /_ / _ \ / _ \ ( _ ) | || | / _ \| ___| >> \ // _ \ '_ \ | || |_| '_ \| | | | | | | |/ _ \ __| || |_| | | |___ \ >> / \ __/ | | | |__ _| (_) | |_| | | |_| | (_) |__|__ _| |_| >> |___) | >> /_/\_\___|_| |_| |_|(_)___(_)___/___\___/ \___/ |_| \___/|____/ >> |_____| >> (XEN) Xen version 4.6.0_08-405 (abuild@suse.de) (gcc (SUSE Linux) >> 4.8.5) debug=n Wed Jan 27 15:23:26 UTC 2016 >> > > .... > >> (XEN) [2016-02-01 05:28:29] d0v0 EPT violation 0x1aa (-w-/r-x) gpa >> 0x000000f100054c mfn 0xf1000 type 5 >> (XEN) [2016-02-01 05:28:29] d0v0 Walking EPT tables for GFN f1000: >> (XEN) [2016-02-01 05:28:29] d0v0 epte 800000084510c107 >> (XEN) [2016-02-01 05:28:29] d0v0 epte 800000085b684107 >> (XEN) [2016-02-01 05:28:29] d0v0 epte 8000000844afb107 >> (XEN) [2016-02-01 05:28:29] d0v0 epte 80500000f1000905 >> (XEN) [2016-02-01 05:28:29] d0v0 --- GLA 0xffffc900006a254c >> (XEN) [2016-02-01 05:28:29] domain_crash called from vmx.c:2685 >> (XEN) [2016-02-01 05:28:29] Domain 0 (vcpu#0) crashed on cpu#0: >> (XEN) [2016-02-01 05:28:29] ----[ Xen-4.6.0_08-405 x86_64 debug=n >> Tainted: C ]---- >> (XEN) [2016-02-01 05:28:29] CPU: 0 >> (XEN) [2016-02-01 05:28:29] RIP: 0010:[<ffffffff8142a4ac>] >> (XEN) [2016-02-01 05:28:29] RFLAGS: 0000000000010246 CONTEXT: hvm >> guest (d0v0) >> (XEN) [2016-02-01 05:28:29] rax: 000000000000000d rbx: >> 00000000f100054c rcx: 000000009e9c4fff >> (XEN) [2016-02-01 05:28:29] rdx: 0000000000000000 rsi: >> 0000000000000100 rdi: ffffffff81eaedc0 >> (XEN) [2016-02-01 05:28:29] rbp: ffff880164b57908 rsp: >> ffff880164b578d8 r8: ffff88016d8c7458 >> (XEN) [2016-02-01 05:28:29] r9: 0000000002400001 r10: >> 0000000000000000 r11: 0000000000002001 >> (XEN) [2016-02-01 05:28:29] r12: 0000000000000020 r13: >> ffff88016453aec0 r14: ffffc900006a254c >> (XEN) [2016-02-01 05:28:29] r15: ffff880164b57a20 cr0: >> 0000000080050033 cr4: 00000000000406b0 >> (XEN) [2016-02-01 05:28:29] cr3: 0000000001e0b000 cr2: 0000000000000000 >> (XEN) [2016-02-01 05:28:29] ds: 0000 es: 0000 fs: 0000 gs: 0000 >> ss: 0000 cs: 0010 >> (XEN) [2016-02-01 05:28:29] Guest stack trace from rsp=ffff880164b578d8: >> (XEN) [2016-02-01 05:28:29] Fault while accessing guest memory. >> (XEN) [2016-02-01 05:28:29] Hardware Dom0 crashed: rebooting machine >> in 5 seconds. > > (+Jan) > > This looks very much like it needs backport of 33c19df9a ("x86/PCI: > intercept accesses to RO MMIO from dom0s in HVM containers") from > unstable, which fixes PVH regression introduced by 9256f66c1606 > ("x86/PCI: intercept all PV Dom0 MMCFG writes") I don't really understand: The former was needed to fix an issue introduced by the latter, but the latter isn't in 4.6 iirc. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 16:56 ` Jan Beulich @ 2016-02-01 19:17 ` Boris Ostrovsky 2016-02-02 9:32 ` Jan Beulich 0 siblings, 1 reply; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-01 19:17 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel, PGNet Dev, wei.liu2, roger.pau On 02/01/2016 11:56 AM, Jan Beulich wrote: >>>> On 01.02.16 at 15:54, <boris.ostrovsky@oracle.com> wrote: >>>> >>>> >>>> This looks very much like it needs backport of 33c19df9a ("x86/PCI: >>>> intercept accesses to RO MMIO from dom0s in HVM containers") from >>>> unstable, which fixes PVH regression introduced by 9256f66c1606 >>>> ("x86/PCI: intercept all PV Dom0 MMCFG writes") > I don't really understand: The former was needed to fix an issue > introduced by the latter, but the latter isn't in 4.6 iirc. > I see it in 4.6, for example http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6;pg=2 and search for "intercept all PV Dom0 MMCFG writes". -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 19:17 ` Boris Ostrovsky @ 2016-02-02 9:32 ` Jan Beulich 0 siblings, 0 replies; 27+ messages in thread From: Jan Beulich @ 2016-02-02 9:32 UTC (permalink / raw) To: Boris Ostrovsky; +Cc: xen-devel, PGNet Dev, wei.liu2, roger.pau >>> On 01.02.16 at 20:17, <boris.ostrovsky@oracle.com> wrote: > On 02/01/2016 11:56 AM, Jan Beulich wrote: >>>>> On 01.02.16 at 15:54, <boris.ostrovsky@oracle.com> wrote: >>>>> >>>>> >>>>> This looks very much like it needs backport of 33c19df9a ("x86/PCI: >>>>> intercept accesses to RO MMIO from dom0s in HVM containers") from >>>>> unstable, which fixes PVH regression introduced by 9256f66c1606 >>>>> ("x86/PCI: intercept all PV Dom0 MMCFG writes") >> I don't really understand: The former was needed to fix an issue >> introduced by the latter, but the latter isn't in 4.6 iirc. >> > > I see it in 4.6, for example > > http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6;p > g=2 > > and search for "intercept all PV Dom0 MMCFG writes". Oh, I'm sorry, I had only looked at what has gone in after 4.6.0. Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 14:54 ` Boris Ostrovsky 2016-02-01 16:56 ` Jan Beulich @ 2016-02-02 15:51 ` Jan Beulich 2016-02-02 16:16 ` PGNet Dev 1 sibling, 1 reply; 27+ messages in thread From: Jan Beulich @ 2016-02-02 15:51 UTC (permalink / raw) To: PGNet Dev; +Cc: Boris Ostrovsky, xen-devel, wei.liu2, roger.pau >>> On 01.02.16 at 15:54, <boris.ostrovsky@oracle.com> wrote: > This looks very much like it needs backport of 33c19df9a ("x86/PCI: > intercept accesses to RO MMIO from dom0s in HVM containers") from > unstable, which fixes PVH regression introduced by 9256f66c1606 > ("x86/PCI: intercept all PV Dom0 MMCFG writes") So would you please confirm that this indeed fixes your issue? I'm hesitant to put it in without confirmation, and it's likely too late for 4.6.1 now anyway (so would then only appear in 4.6.2). Jan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-02 15:51 ` Jan Beulich @ 2016-02-02 16:16 ` PGNet Dev 0 siblings, 0 replies; 27+ messages in thread From: PGNet Dev @ 2016-02-02 16:16 UTC (permalink / raw) To: JBeulich; +Cc: boris.ostrovsky, xen-devel, wei.liu2, roger.pau On 02/02/2016 07:51 AM, Jan Beulich wrote: > So would you please confirm that this indeed fixes your issue? > I'm hesitant to put it in without confirmation, and it's likely too > late for 4.6.1 now anyway (so would then only appear in 4.6.2). I don't build Xen. I use packages provided by Opensuse distro @ http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.1 Happy to test any built/installable packages. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-01-31 21:27 Clarifying PVH mode requirements PGNet Dev 2016-02-01 3:47 ` PGNet Dev 2016-02-01 9:59 ` Wei Liu @ 2016-02-01 10:28 ` Roger Pau Monné 2016-02-01 12:30 ` PGNet Dev 2016-02-01 14:11 ` Boris Ostrovsky 2 siblings, 2 replies; 27+ messages in thread From: Roger Pau Monné @ 2016-02-01 10:28 UTC (permalink / raw) To: PGNet Dev, xen-devel; +Cc: Mukesh Rathor, Boris Ostrovsky El 31/01/16 a les 22.27, PGNet Dev ha escrit: > I run Xen 4.6 Dom0 > > rpm -qa | egrep -i "kernel-default-4|xen-4" > kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64 > xen-4.6.0_08-405.1.x86_64 Are your kernels compiled with CONFIG_PVH enabled? > My guests are currently HVM in PVHVM mode; I'm exploring PVH. > > IIUC, for 4.6, this doc > > http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt > > instructs the following necessary changes: > > @ GRUBG cfg > > - GRUB_CMDLINE_XEN=" ..." > + GRUB_CMDLINE_XEN=" dom0pvh ..." > > &, @ guest.cfg > > + pvh = 1 > > For my guest.cfg, currently in PVHVM mode, I have > > builder = 'hvm' > xen_platform_pci = 1 > device_model_version="qemu-xen" > hap = 1 > ... > > Q: > Do any of these^^ params need to also change with the addition of > > pvh = 1 Yes, you need to remove builder, xen_platform_pci and device_model_version, and add a kernel and ramdisk parameters that point to the actual kernel and ramdisk that you want to use. The file should look like: kernel = "/path/to/kernel" ramdisk = "/path/to/ramdisk" pvh=1 hap=1 [... other options, memory, vcpus ...] The paths in the kernel and ramdisk options are relative to Dom0, not DomU. You can also use pygrub if you prefer, by removing the kernel/ramdisk options and setting the bootloader one: bootloader="pygrub" > >> At the moment HAP is required for PVH. > > As above, I've 'hap = 1' enabled. > > But checking cpu, > > hwinfo --cpu | egrep "Arch|Model" > Arch: X86-64 > Model: 6.60.3 "Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz" You CPU is perfectly capable of running both a PVH Dom0 or DomU, check: http://ark.intel.com/products/52269/Intel-Xeon-Processor-E3-1220-8M-Cache-3_10-GHz Look for EPT and VT-d which are the main requirements for PVH. > Q: > Am I out of luck re: PVH with more modern Haswell? Or is there a > different check I should be running ? > >> At present the only PVH guest is an x86 64bit PV linux. > > Is this still current/true info? IIRC Boris (CCed) added support for 32bit PVH to Linux, so you should be able to use either 32 or 64 kernels. Roger. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 10:28 ` Roger Pau Monné @ 2016-02-01 12:30 ` PGNet Dev 2016-02-01 14:11 ` Boris Ostrovsky 1 sibling, 0 replies; 27+ messages in thread From: PGNet Dev @ 2016-02-01 12:30 UTC (permalink / raw) To: roger.pau, xen-devel; +Cc: boris.ostrovsky On 02/01/2016 02:28 AM, Roger Pau Monné wrote: >> Do any of these^^ params need to also change with the addition of >> >> pvh = 1 > > Yes, you need to remove builder, xen_platform_pci and > device_model_version, and add a kernel and ramdisk parameters that point > to the actual kernel and ramdisk that you want to use. The file should > look like: Got it now. It's a PVH config to start, not an HVM -- different than PVHVM ... >> But checking cpu, >> >> hwinfo --cpu | egrep "Arch|Model" >> Arch: X86-64 >> Model: 6.60.3 "Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz" > > You CPU is perfectly capable of running both a PVH Dom0 or DomU, check: > > http://ark.intel.com/products/52269/Intel-Xeon-Processor-E3-1220-8M-Cache-3_10-GHz > > Look for EPT and VT-d which are the main requirements for PVH. Clear enough. Guess it's presumed in 'modern' VT-x; odd that cat /proc/cpuinfo provides no indication ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 10:28 ` Roger Pau Monné 2016-02-01 12:30 ` PGNet Dev @ 2016-02-01 14:11 ` Boris Ostrovsky 2016-02-01 15:49 ` PGNet Dev 1 sibling, 1 reply; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-01 14:11 UTC (permalink / raw) To: Roger Pau Monné, PGNet Dev, xen-devel On 02/01/2016 05:28 AM, Roger Pau Monné wrote: > IIRC Boris (CCed) added support for 32bit PVH to Linux, so you should > be able to use either 32 or 64 kernels. Roger. This actually never happened for Linux: HVMlite showed up fast enough that it didn't make sense anymore to add 32-bit support to Linux (especially given that AMD was still not supported). -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 14:11 ` Boris Ostrovsky @ 2016-02-01 15:49 ` PGNet Dev 2016-02-01 19:14 ` Boris Ostrovsky 0 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-01 15:49 UTC (permalink / raw) To: boris.ostrovsky, roger.pau, xen-devel On 02/01/2016 06:11 AM, Boris Ostrovsky wrote: > This actually never happened for Linux: HVMlite showed up fast enough > that it didn't make sense anymore to add 32-bit support to Linux > (especially given that AMD was still not supported). Is 'HVMLite' replacing 'PVH'? Or are they separate modes? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 15:49 ` PGNet Dev @ 2016-02-01 19:14 ` Boris Ostrovsky 2016-02-01 19:27 ` PGNet Dev 0 siblings, 1 reply; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-01 19:14 UTC (permalink / raw) To: PGNet Dev, roger.pau, xen-devel On 02/01/2016 10:49 AM, PGNet Dev wrote: > On 02/01/2016 06:11 AM, Boris Ostrovsky wrote: >> This actually never happened for Linux: HVMlite showed up fast enough >> that it didn't make sense anymore to add 32-bit support to Linux >> (especially given that AMD was still not supported). > > Is 'HVMLite' replacing 'PVH'? Or are they separate modes? Yes, HVMlite is replacing PVH. Probably once we get dom0 support. -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 19:14 ` Boris Ostrovsky @ 2016-02-01 19:27 ` PGNet Dev 2016-02-01 19:58 ` Boris Ostrovsky 0 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-01 19:27 UTC (permalink / raw) To: boris.ostrovsky, xen-devel On 02/01/2016 11:14 AM, Boris Ostrovsky wrote: >> Is 'HVMLite' replacing 'PVH'? Or are they separate modes? > > Yes, HVMlite is replacing PVH. Probably once we get dom0 support. If that's a 'done deal', and it sounds like it is, it'd be useful to have it integrated into: http://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum particularly as there's no mention of HVMlite on the wiki, at all. It's unclear whether PVH, in its current dev state (at least here), is worth-the-visit -- especially if HVMlite is "ComingSoon(tm)". I suppose I'm looking for some guidance as to which to invest time in while on Xen 4.6.0, ack'ing that neither PVH nor HVMlite are production-ready. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 19:27 ` PGNet Dev @ 2016-02-01 19:58 ` Boris Ostrovsky 2016-02-01 23:49 ` Brendan Gregg 0 siblings, 1 reply; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-01 19:58 UTC (permalink / raw) To: PGNet Dev, xen-devel On 02/01/2016 02:27 PM, PGNet Dev wrote: > On 02/01/2016 11:14 AM, Boris Ostrovsky wrote: >>> Is 'HVMLite' replacing 'PVH'? Or are they separate modes? >> >> Yes, HVMlite is replacing PVH. Probably once we get dom0 support. > > If that's a 'done deal', and it sounds like it is, it'd be useful to > have it integrated into: > > http://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum > > particularly as there's no mention of HVMlite on the wiki, at all. HVMlite is very new: domU hypervisor support has been added less than two months ago and Linux patches are being reviewed as we speak (FreeBSD, I believe, is supported). > > It's unclear whether PVH, in its current dev state (at least here), is > worth-the-visit -- especially if HVMlite is "ComingSoon(tm)". > > I suppose I'm looking for some guidance as to which to invest time in > while on Xen 4.6.0, ack'ing that neither PVH nor HVMlite are > production-ready. Current PVH implementation has never been described as production-ready. What is happening now with HVMlite is essentially bringing PVH to production-quality level. -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 19:58 ` Boris Ostrovsky @ 2016-02-01 23:49 ` Brendan Gregg 2016-02-02 15:28 ` Boris Ostrovsky 0 siblings, 1 reply; 27+ messages in thread From: Brendan Gregg @ 2016-02-01 23:49 UTC (permalink / raw) To: Boris Ostrovsky; +Cc: xen-devel, PGNet Dev [-- Attachment #1.1: Type: text/plain, Size: 1690 bytes --] On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky <boris.ostrovsky@oracle.com > wrote: > On 02/01/2016 02:27 PM, PGNet Dev wrote: > >> On 02/01/2016 11:14 AM, Boris Ostrovsky wrote: >> >>> Is 'HVMLite' replacing 'PVH'? Or are they separate modes? >>>> >>> >>> Yes, HVMlite is replacing PVH. Probably once we get dom0 support. >>> >> >> If that's a 'done deal', and it sounds like it is, it'd be useful to have >> it integrated into: >> >> http://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum >> >> particularly as there's no mention of HVMlite on the wiki, at all. >> > Thanks, HVMlite is new to me. I created the Xen modes diagram on this page (based on the older modes diagram; if anyone wants the new omnigraffle source, email me), and I just created a Xen wiki account so I can update this page. I've been meaning to update this modes diagram anyway, and improve the columns. > HVMlite is very new: domU hypervisor support has been added less than two > months ago and Linux patches are being reviewed as we speak (FreeBSD, I > believe, is supported). > > >> It's unclear whether PVH, in its current dev state (at least here), is >> worth-the-visit -- especially if HVMlite is "ComingSoon(tm)". >> >> I suppose I'm looking for some guidance as to which to invest time in >> while on Xen 4.6.0, ack'ing that neither PVH nor HVMlite are >> production-ready. >> > > Current PVH implementation has never been described as production-ready. > What is happening now with HVMlite is essentially bringing PVH to > production-quality level. So should I s/PVH/HVMlite/g? Or too much of a simlification? thanks, Brendan -- Brendan Gregg, Senior Performance Architect, Netflix [-- Attachment #1.2: Type: text/html, Size: 3104 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] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-01 23:49 ` Brendan Gregg @ 2016-02-02 15:28 ` Boris Ostrovsky 2016-02-04 22:01 ` PGNet Dev 0 siblings, 1 reply; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-02 15:28 UTC (permalink / raw) To: Brendan Gregg; +Cc: xen-devel, PGNet Dev On 02/01/2016 06:49 PM, Brendan Gregg wrote: > > > On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky > <boris.ostrovsky@oracle.com <mailto:boris.ostrovsky@oracle.com>> wrote: > > > Current PVH implementation has never been described as > production-ready. What is happening now with HVMlite is > essentially bringing PVH to production-quality level. > > > So should I s/PVH/HVMlite/g? From user perspective that will be almost true. I am not sure it should be classified as PV mode anymore since it's really an HVM guest without any devices. But it's not there yet so it's too early to point your editor there. BTW, I don't think the flowchart in the wiki is correct as far as PVH is concerned --- you can't use PVH unless HVM (and, in fact, PVHVM) is supported. -boris > Or too much of a simlification? thanks, ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-02 15:28 ` Boris Ostrovsky @ 2016-02-04 22:01 ` PGNet Dev 2016-02-04 22:39 ` Boris Ostrovsky 0 siblings, 1 reply; 27+ messages in thread From: PGNet Dev @ 2016-02-04 22:01 UTC (permalink / raw) To: boris.ostrovsky, bgregg; +Cc: xen-devel >> On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky >> Current PVH implementation has never been described as >> production-ready. What is happening now with HVMlite is >> essentially bringing PVH to production-quality level. >> >> >> So should I s/PVH/HVMlite/g? > > From user perspective that will be almost true. I am not sure it should > be classified as PV mode anymore since it's really an HVM guest without > any devices. But it's not there yet so it's too early to point your > editor there. > > BTW, I don't think the flowchart in the wiki is correct as far as PVH is > concerned --- you can't use PVH unless HVM (and, in fact, PVHVM) is > supported. Noting the very recent flurry of HVMLite activity, so where does PVH sit? As it's not production-ready (and, atm, unusable here), is it planned to be? Or is it being simply leap-frogged by HVMLite? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Clarifying PVH mode requirements 2016-02-04 22:01 ` PGNet Dev @ 2016-02-04 22:39 ` Boris Ostrovsky 0 siblings, 0 replies; 27+ messages in thread From: Boris Ostrovsky @ 2016-02-04 22:39 UTC (permalink / raw) To: PGNet Dev, bgregg; +Cc: xen-devel On 02/04/2016 05:01 PM, PGNet Dev wrote: >>> On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky >>> Current PVH implementation has never been described as >>> production-ready. What is happening now with HVMlite is >>> essentially bringing PVH to production-quality level. >>> >>> >>> So should I s/PVH/HVMlite/g? >> >> From user perspective that will be almost true. I am not sure it should >> be classified as PV mode anymore since it's really an HVM guest without >> any devices. But it's not there yet so it's too early to point your >> editor there. >> >> BTW, I don't think the flowchart in the wiki is correct as far as PVH is >> concerned --- you can't use PVH unless HVM (and, in fact, PVHVM) is >> supported. > > Noting the very recent flurry of HVMLite activity, so where does PVH sit? > > As it's not production-ready (and, atm, unusable here), is it planned > to be? Not the current implementation. > Or is it being simply leap-frogged by HVMLite? > I don't know about "leap-frogged", I think you might say PVH evolved into HVMlite? -boris ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2016-02-04 22:39 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-31 21:27 Clarifying PVH mode requirements PGNet Dev 2016-02-01 3:47 ` PGNet Dev 2016-02-01 10:30 ` Roger Pau Monné 2016-02-01 12:16 ` PGNet Dev 2016-02-01 9:59 ` Wei Liu 2016-02-01 12:23 ` PGNet Dev 2016-02-01 12:29 ` Wei Liu 2016-02-01 12:29 ` Roger Pau Monné 2016-02-01 12:38 ` PGNet Dev 2016-02-01 13:38 ` PGNet Dev 2016-02-01 14:54 ` Boris Ostrovsky 2016-02-01 16:56 ` Jan Beulich 2016-02-01 19:17 ` Boris Ostrovsky 2016-02-02 9:32 ` Jan Beulich 2016-02-02 15:51 ` Jan Beulich 2016-02-02 16:16 ` PGNet Dev 2016-02-01 10:28 ` Roger Pau Monné 2016-02-01 12:30 ` PGNet Dev 2016-02-01 14:11 ` Boris Ostrovsky 2016-02-01 15:49 ` PGNet Dev 2016-02-01 19:14 ` Boris Ostrovsky 2016-02-01 19:27 ` PGNet Dev 2016-02-01 19:58 ` Boris Ostrovsky 2016-02-01 23:49 ` Brendan Gregg 2016-02-02 15:28 ` Boris Ostrovsky 2016-02-04 22:01 ` PGNet Dev 2016-02-04 22:39 ` Boris Ostrovsky
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.