* 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-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-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 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-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 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 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 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 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: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 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 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 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: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 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 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-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-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.