2008-02-22 11:30:21

by Arnd Hannemann

[permalink] [raw]
Subject: [PATCH] let XEN depend on PAE

Hi,

As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
accordingly.

Signed-off-by: Arnd Hannemann <[email protected]>

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 4d5f264..2035238 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -6,7 +6,7 @@ config XEN
bool "Xen guest support"
select PARAVIRT
depends on X86_32
- depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES && !(X86_VISWS ||
X86_VOYAGER)
+ depends on X86_PAE && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES &&
!(X86_VISWS || X86_VOYAGER)
help
This is the Linux Xen port. Enabling this will allow the
kernel to boot in a paravirtualized environment under the


2008-02-22 13:37:31

by Ian Campbell

[permalink] [raw]
Subject: Re: [PATCH] let XEN depend on PAE


On Fri, 2008-02-22 at 12:00 +0100, Arnd Hannemann wrote:
> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
> accordingly.

Really? Xen guests should work on non-PAE if you have a non-PAE
hypervisor (which most distros don't ship but which does exist).

Ian.

--
Ian Campbell
Current Noise: The Ocean - Mesoproterozoic - Calymmian - Lake Disappointment

"World domination. Fast"
(By Linus Torvalds)

2008-02-22 15:00:12

by Arnd Hannemann

[permalink] [raw]
Subject: Re: [PATCH] let XEN depend on PAE

Ian Campbell schrieb:
> On Fri, 2008-02-22 at 12:00 +0100, Arnd Hannemann wrote:
>> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
>> accordingly.
>
> Really? Xen guests should work on non-PAE if you have a non-PAE
> hypervisor (which most distros don't ship but which does exist).

Well if it should work, then something else is broken.
I have a non-PAE hypervisor, still xen guests compiled with !X86_PAE
from 2.6.24.2 and latest git won't work.
All the same with PAE enabled works.

http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00716.html

>
> Ian.
>

Best regards,
Arnd

2008-02-22 16:40:03

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Arnd Hannemann wrote:
> As paravirtualized xen guests won't work with !X86_PAE, change the Kconfig
> accordingly.
>

!PAE is supposed to work, but it is a rarely used configuration. How
does it fail?

J

2008-02-22 16:54:41

by Arnd Hannemann

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Jeremy Fitzhardinge schrieb:
> Arnd Hannemann wrote:
>> As paravirtualized xen guests won't work with !X86_PAE, change the
>> Kconfig
>> accordingly.
>>
>
> !PAE is supposed to work, but it is a rarely used configuration. How
> does it fail?
>
> J
>

This is with 2.6.24.2, but latest-git looks the same:
I also tried with 2.6.23 which crashes instantly, without any output of the guest.

[ 0.599806] 1 multicall(s) failed: cpu 0
[ 0.599816] call 1/2: op=26 arg=[c1051860] result=0
[ 0.599825] call 2/2: op=14 arg=[bf9c7000] result=-22
[ 0.599841] ------------[ cut here ]------------
[ 0.599851] kernel BUG at arch/x86/xen/multicalls.c:103!
[ 0.599861] invalid opcode: 0000 [#1] SMP
[ 0.599871] Modules linked in:
[ 0.599879]
[ 0.599885] Pid: 1, comm: init Not tainted (2.6.24.2 #6)
[ 0.599895] EIP: 0061:[<c0101b7c>] EFLAGS: 00010202 CPU: 0
[ 0.599910] EIP is at xen_mc_flush+0x19c/0x1b0
[ 0.599919] EAX: 00000000 EBX: c10510a0 ECX: c1051060 EDX: c1051060
[ 0.599930] ESI: 00000002 EDI: 00000001 EBP: c2417c10 ESP: c2417be4
[ 0.599940] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
[ 0.599951] Process init (pid: 1, ti=c2417000 task=c2416ab0 task.ti=c2417000)
[ 0.599960] Stack: c0443c98 00000002 00000002 0000000e bf9c7000 ffffffea c1051060 00000200
[ 0.599984] 00000067 c193fffc bf9c7000 c2417c18 c0101112 c2417c5c c0166dfc c193ce40
[ 0.600006] c193e5c0 c0000000 c193e5c0 00001000 c0000000 c193ce40 c198e71c c10331cc
[ 0.600029] Call Trace:
[ 0.600036] [<c0107a6a>] show_trace_log_lvl+0x1a/0x30
[ 0.600050] [<c0107b29>] show_stack_log_lvl+0xa9/0xd0
[ 0.600062] [<c0107c1a>] show_registers+0xca/0x1e0
[ 0.600074] [<c0107e4a>] die+0x11a/0x250
[ 0.600085] [<c0108003>] do_trap+0x83/0xb0
[ 0.600096] [<c0108318>] do_invalid_op+0x88/0xa0
[ 0.600108] [<c03e89d2>] error_code+0x72/0x80
[ 0.600121] [<c0101112>] xen_leave_lazy+0x12/0x20
[ 0.600134] [<c0166dfc>] move_page_tables+0x27c/0x300
[ 0.600149] [<c0174762>] setup_arg_pages+0x162/0x2a0
[ 0.600162] [<c019cad3>] load_elf_binary+0x3d3/0x1bd0
[ 0.600175] [<c0173f92>] search_binary_handler+0x92/0x200
[ 0.600190] [<c019b1ef>] load_script+0x1bf/0x200
[ 0.600202] [<c0173f92>] search_binary_handler+0x92/0x200
[ 0.600215] [<c0175bab>] do_execve+0x15b/0x180
[ 0.600227] [<c0104a2e>] sys_execve+0x2e/0x80
[ 0.600241] [<c0106342>] syscall_call+0x7/0xb
[ 0.600253] =======================
[ 0.600259] Code: 24 08 89 44 24 0c 89 74 24 04 c7 04 24 98 3c 44 c0 e8 c9 36 02 00 8b 45 ec 83 c3 20 8b 90 00 0b 00 00 39 d6 72 c0 e9 04 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 00 00 00 55
[ 0.600370] EIP: [<c0101b7c>] xen_mc_flush+0x19c/0x1b0 SS:ESP e021:c2417be4
[ 0.600393] ---[ end trace a686db401f06e173 ]---
[ 0.600403] Kernel panic - not syncing: Attempted to kill init!

full dmesg, config here:
http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00716.html

Best regards,
Arnd Hannemann

2008-02-22 19:02:06

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Arnd Hannemann wrote:
> This is with 2.6.24.2, but latest-git looks the same:
> I also tried with 2.6.23 which crashes instantly, without any output of the guest.
>

I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
gets tested rarely. Chris Wright did spend some time on it a while ago,
but I don't know that its had any real attention since. I've been
making sure non-PAE compiles, but I've been lax about testing it.

This is the first usermode exec, I guess? The backtrace is a bit odd;
I've never seen a problem in move_page_tables before.

Does "xm dmesg" tell you what Xen is complaining about? You may need to
compile with debug=y in Config.mk.

> [ 0.599806] 1 multicall(s) failed: cpu 0
> [ 0.599816] call 1/2: op=26 arg=[c1051860] result=0
> [ 0.599825] call 2/2: op=14 arg=[bf9c7000] result=-22
> [ 0.599841] ------------[ cut here ]------------
> [ 0.599851] kernel BUG at arch/x86/xen/multicalls.c:103!
> [ 0.599861] invalid opcode: 0000 [#1] SMP
> [ 0.599871] Modules linked in:
> [ 0.599879]
> [ 0.599885] Pid: 1, comm: init Not tainted (2.6.24.2 #6)
> [ 0.599895] EIP: 0061:[<c0101b7c>] EFLAGS: 00010202 CPU: 0
> [ 0.599910] EIP is at xen_mc_flush+0x19c/0x1b0
> [ 0.599919] EAX: 00000000 EBX: c10510a0 ECX: c1051060 EDX: c1051060
> [ 0.599930] ESI: 00000002 EDI: 00000001 EBP: c2417c10 ESP: c2417be4
> [ 0.599940] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
> [ 0.599951] Process init (pid: 1, ti=c2417000 task=c2416ab0 task.ti=c2417000)
> [ 0.599960] Stack: c0443c98 00000002 00000002 0000000e bf9c7000 ffffffea c1051060 00000200
> [ 0.599984] 00000067 c193fffc bf9c7000 c2417c18 c0101112 c2417c5c c0166dfc c193ce40
> [ 0.600006] c193e5c0 c0000000 c193e5c0 00001000 c0000000 c193ce40 c198e71c c10331cc
> [ 0.600029] Call Trace:
> [ 0.600036] [<c0107a6a>] show_trace_log_lvl+0x1a/0x30
> [ 0.600050] [<c0107b29>] show_stack_log_lvl+0xa9/0xd0
> [ 0.600062] [<c0107c1a>] show_registers+0xca/0x1e0
> [ 0.600074] [<c0107e4a>] die+0x11a/0x250
> [ 0.600085] [<c0108003>] do_trap+0x83/0xb0
> [ 0.600096] [<c0108318>] do_invalid_op+0x88/0xa0
> [ 0.600108] [<c03e89d2>] error_code+0x72/0x80
> [ 0.600121] [<c0101112>] xen_leave_lazy+0x12/0x20
> [ 0.600134] [<c0166dfc>] move_page_tables+0x27c/0x300
> [ 0.600149] [<c0174762>] setup_arg_pages+0x162/0x2a0
> [ 0.600162] [<c019cad3>] load_elf_binary+0x3d3/0x1bd0
> [ 0.600175] [<c0173f92>] search_binary_handler+0x92/0x200
> [ 0.600190] [<c019b1ef>] load_script+0x1bf/0x200
> [ 0.600202] [<c0173f92>] search_binary_handler+0x92/0x200
> [ 0.600215] [<c0175bab>] do_execve+0x15b/0x180
> [ 0.600227] [<c0104a2e>] sys_execve+0x2e/0x80
> [ 0.600241] [<c0106342>] syscall_call+0x7/0xb
> [ 0.600253] =======================
> [ 0.600259] Code: 24 08 89 44 24 0c 89 74 24 04 c7 04 24 98 3c 44 c0 e8 c9 36 02 00 8b 45 ec 83 c3 20 8b 90 00 0b 00 00 39 d6 72 c0 e9 04 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 00 00 00 55
> [ 0.600370] EIP: [<c0101b7c>] xen_mc_flush+0x19c/0x1b0 SS:ESP e021:c2417be4
> [ 0.600393] ---[ end trace a686db401f06e173 ]---
> [ 0.600403] Kernel panic - not syncing: Attempted to kill init!
>
> full dmesg, config here:
> http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00716.html
>
> Best regards,
> Arnd Hannemann
>
>

J

2008-02-22 19:45:42

by Arnd Hannemann

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Jeremy Fitzhardinge wrote:
> Arnd Hannemann wrote:
>> This is with 2.6.24.2, but latest-git looks the same:
>> I also tried with 2.6.23 which crashes instantly, without any output
>> of the guest.
>>
>
> I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
> gets tested rarely. Chris Wright did spend some time on it a while ago,
> but I don't know that its had any real attention since. I've been
> making sure non-PAE compiles, but I've been lax about testing it.
> This is the first usermode exec, I guess? The backtrace is a bit odd;
> I've never seen a problem in move_page_tables before.

Yes its trying to execute the first script in initramfs, I also tried with initramdisk
and got a similar error. (move_page_tables also involved)

>
> Does "xm dmesg" tell you what Xen is complaining about? You may need to
> compile with debug=y in Config.mk.

(XEN) mm.c:645:d44 Non-privileged (44) attempt to map I/O space 00000000

I will recompile with debug=y and post the output.
If I reduce the dom0 memory with dom0_mem=200000 I see something like
00000080 with dom0_mem=800000 I always see 00000000.

>
>> [ 0.599806] 1 multicall(s) failed: cpu 0
>> [ 0.599816] call 1/2: op=26 arg=[c1051860] result=0
>> [ 0.599825] call 2/2: op=14 arg=[bf9c7000] result=-22
>> [ 0.599841] ------------[ cut here ]------------
>> [ 0.599851] kernel BUG at arch/x86/xen/multicalls.c:103!
>> [ 0.599861] invalid opcode: 0000 [#1] SMP
>> [ 0.599871] Modules linked in:
>> [ 0.599879]
>> [ 0.599885] Pid: 1, comm: init Not tainted (2.6.24.2 #6)
>> [ 0.599895] EIP: 0061:[<c0101b7c>] EFLAGS: 00010202 CPU: 0
>> [ 0.599910] EIP is at xen_mc_flush+0x19c/0x1b0
>> [ 0.599919] EAX: 00000000 EBX: c10510a0 ECX: c1051060 EDX: c1051060
>> [ 0.599930] ESI: 00000002 EDI: 00000001 EBP: c2417c10 ESP: c2417be4
>> [ 0.599940] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: e021
>> [ 0.599951] Process init (pid: 1, ti=c2417000 task=c2416ab0
>> task.ti=c2417000)
>> [ 0.599960] Stack: c0443c98 00000002 00000002 0000000e bf9c7000
>> ffffffea c1051060 00000200
>> [ 0.599984] 00000067 c193fffc bf9c7000 c2417c18 c0101112
>> c2417c5c c0166dfc c193ce40
>> [ 0.600006] c193e5c0 c0000000 c193e5c0 00001000 c0000000
>> c193ce40 c198e71c c10331cc
>> [ 0.600029] Call Trace:
>> [ 0.600036] [<c0107a6a>] show_trace_log_lvl+0x1a/0x30
>> [ 0.600050] [<c0107b29>] show_stack_log_lvl+0xa9/0xd0
>> [ 0.600062] [<c0107c1a>] show_registers+0xca/0x1e0
>> [ 0.600074] [<c0107e4a>] die+0x11a/0x250
>> [ 0.600085] [<c0108003>] do_trap+0x83/0xb0
>> [ 0.600096] [<c0108318>] do_invalid_op+0x88/0xa0
>> [ 0.600108] [<c03e89d2>] error_code+0x72/0x80
>> [ 0.600121] [<c0101112>] xen_leave_lazy+0x12/0x20
>> [ 0.600134] [<c0166dfc>] move_page_tables+0x27c/0x300
>> [ 0.600149] [<c0174762>] setup_arg_pages+0x162/0x2a0
>> [ 0.600162] [<c019cad3>] load_elf_binary+0x3d3/0x1bd0
>> [ 0.600175] [<c0173f92>] search_binary_handler+0x92/0x200
>> [ 0.600190] [<c019b1ef>] load_script+0x1bf/0x200
>> [ 0.600202] [<c0173f92>] search_binary_handler+0x92/0x200
>> [ 0.600215] [<c0175bab>] do_execve+0x15b/0x180
>> [ 0.600227] [<c0104a2e>] sys_execve+0x2e/0x80
>> [ 0.600241] [<c0106342>] syscall_call+0x7/0xb
>> [ 0.600253] =======================
>> [ 0.600259] Code: 24 08 89 44 24 0c 89 74 24 04 c7 04 24 98 3c 44
>> c0 e8 c9 36 02 00 8b 45 ec 83 c3 20 8b 90 00 0b 00 00 39 d6 72 c0 e9
>> 04 ff ff ff <0f> 0b eb fe 0f 0b eb fe 8d b6 00 00 00 00 8d bf 00 00 00
>> 00 55
>> [ 0.600370] EIP: [<c0101b7c>] xen_mc_flush+0x19c/0x1b0 SS:ESP
>> e021:c2417be4
>> [ 0.600393] ---[ end trace a686db401f06e173 ]---
>> [ 0.600403] Kernel panic - not syncing: Attempted to kill init!
>>
>> full dmesg, config here:
>> http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00716.html
>>
>> Best regards,
>> Arnd Hannemann
>>
>>
>
> J
>

2008-02-22 21:17:19

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Arnd Hannemann wrote:
> Jeremy Fitzhardinge wrote:
>
>> Arnd Hannemann wrote:
>>
>>> This is with 2.6.24.2, but latest-git looks the same:
>>> I also tried with 2.6.23 which crashes instantly, without any output
>>> of the guest.
>>>
>>>
>> I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
>> gets tested rarely. Chris Wright did spend some time on it a while ago,
>> but I don't know that its had any real attention since. I've been
>> making sure non-PAE compiles, but I've been lax about testing it.
>> This is the first usermode exec, I guess? The backtrace is a bit odd;
>> I've never seen a problem in move_page_tables before.
>>
>
> Yes its trying to execute the first script in initramfs, I also tried with initramdisk
> and got a similar error. (move_page_tables also involved)
>
>
>> Does "xm dmesg" tell you what Xen is complaining about? You may need to
>> compile with debug=y in Config.mk.
>>
>
> (XEN) mm.c:645:d44 Non-privileged (44) attempt to map I/O space 00000000
>
> I will recompile with debug=y and post the output.
> If I reduce the dom0 memory with dom0_mem=200000 I see something like
> 00000080 with dom0_mem=800000 I always see 00000000.
>

That's helpful. Looks like the mfn is getting mushed to 0.

J

2008-02-23 12:36:54

by Arnd Hannemann

[permalink] [raw]
Subject: Re: [Xen-devel] [PATCH] let XEN depend on PAE

Arnd Hannemann wrote:
> Jeremy Fitzhardinge wrote:
>> Arnd Hannemann wrote:
>>> This is with 2.6.24.2, but latest-git looks the same:
>>> I also tried with 2.6.23 which crashes instantly, without any output
>>> of the guest.
>>>
>> I'm not too surprised. Non-PAE Xen is a bit of a rarity, and it only
>> gets tested rarely. Chris Wright did spend some time on it a while ago,
>> but I don't know that its had any real attention since. I've been
>> making sure non-PAE compiles, but I've been lax about testing it.
>> This is the first usermode exec, I guess? The backtrace is a bit odd;
>> I've never seen a problem in move_page_tables before.
>
> Yes its trying to execute the first script in initramfs, I also tried with initramdisk
> and got a similar error. (move_page_tables also involved)
>
>> Does "xm dmesg" tell you what Xen is complaining about? You may need to
>> compile with debug=y in Config.mk.
>
> (XEN) mm.c:645:d44 Non-privileged (44) attempt to map I/O space 00000000
>
> I will recompile with debug=y and post the output.

I recompiled with debug=y but no more information than above message...

[snip]

Arnd