Latest bk can NOT compile on x86_64

Latest bk can NOT compile on x86_64

[Li, Xin B]

When doing "make linux-2.6-xen0-build", it failed with:

make[3]: `arch/xen/x86_64/kernel/asm-offsets.s' is up to date.
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function `xen_idle':
: undefined reference to `set_timeout_timer'
make[2]: *** [.tmp_vmlinux1] Error 1
make[2]: Leaving directory
`/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'
make: *** [linux-2.6-xen0-build] Error 2

-Xin

RE: Latest bk can NOT compile on x86_64

[Nakajima, Jun]

Actually xen itself is broken (again) too on x86-64. It dies like the
below. I think the breakage happened very recently (today, yesterday, or
the day before yesterday). 
---
 Xen version 3.0-devel (jnakajim@sc.intel.com) (gcc version 3.4.2
20041017 (Red
Hat 3.4.2-6.fc3)) Mon May 30 21:26:28 PDT 2005
 Latest ChangeSet: 2005/05/30 20:19:59 1.1577
429bd7dfnKHSDeYeOeCr4yRO7YCrFQ

(XEN) Physical RAM map:
(XEN)  0000000000000000 - 000000000009fc00 (usable)
(XEN)  000000000009fc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e6000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000003f630000 (usable)
(XEN)  000000003f630000 - 000000003f640000 (ACPI data)
(XEN)  000000003f640000 - 000000003f6f0000 (ACPI NVS)
(XEN)  000000003f6f0000 - 000000003f800000 (reserved)
(XEN)  00000000cff00000 - 00000000f0000000 (reserved)
(XEN)  00000000fed13000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
(XEN) System RAM: 1013MB (1038140kB)
(XEN) Xen heap: 14MB (14828kB)
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 2048K
(XEN) Unknown interrupt

Li, Xin B wrote:
> When doing "make linux-2.6-xen0-build", it failed with:
> 
> make[3]: `arch/xen/x86_64/kernel/asm-offsets.s' is up to date.
>   CHK     include/linux/compile.h
>   CHK     usr/initramfs_list
>   GEN     .version
>   CHK     include/linux/compile.h
>   UPD     include/linux/compile.h
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function
> `xen_idle': 
>> undefined reference to `set_timeout_timer'
> make[2]: *** [.tmp_vmlinux1] Error 1
> make[2]: Leaving directory
> `/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'
> make[1]: *** [build] Error 2
> make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'
> make: *** [linux-2.6-xen0-build] Error 2
> 
> -Xin
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



Jun
---
Intel Open Source Technology Center

RE: Latest bk can NOT compile on x86_64

[Nakajima, Jun]

Nakajima, Jun wrote:
> Actually xen itself is broken (again) too on x86-64. It dies like the
> below. I think the breakage happened very recently (today, yesterday,
> or the day before yesterday).

Did a quick debugging. It's failing at phys_pkg_id (it's NULL) in
detect_ht because genacpi is not set yet when this is called. Putting
"apic=default" makes it boot. I think it should be initialized as
"default".

void __init detect_ht(struct cpuinfo_x86 *c) {
...
	phys_proc_id[cpu] = phys_pkg_id((ebx >> 24) & 0xFF, index_msb);

Jun
---
Intel Open Source Technology Center

> ---
>  Xen version 3.0-devel (jnakajim@sc.intel.com) (gcc version 3.4.2
> 20041017 (Red
> Hat 3.4.2-6.fc3)) Mon May 30 21:26:28 PDT 2005
>  Latest ChangeSet: 2005/05/30 20:19:59 1.1577
> 429bd7dfnKHSDeYeOeCr4yRO7YCrFQ
> 
> (XEN) Physical RAM map:
> (XEN)  0000000000000000 - 000000000009fc00 (usable)
> (XEN)  000000000009fc00 - 00000000000a0000 (reserved)
> (XEN)  00000000000e6000 - 0000000000100000 (reserved)
> (XEN)  0000000000100000 - 000000003f630000 (usable)
> (XEN)  000000003f630000 - 000000003f640000 (ACPI data)
> (XEN)  000000003f640000 - 000000003f6f0000 (ACPI NVS)
> (XEN)  000000003f6f0000 - 000000003f800000 (reserved)
> (XEN)  00000000cff00000 - 00000000f0000000 (reserved)
> (XEN)  00000000fed13000 - 00000000fed1a000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
> (XEN) System RAM: 1013MB (1038140kB)
> (XEN) Xen heap: 14MB (14828kB)
> (XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
> (XEN) CPU: L2 cache: 2048K
> (XEN) Unknown interrupt
> 
> Li, Xin B wrote:
>> When doing "make linux-2.6-xen0-build", it failed with:
>> 
>> make[3]: `arch/xen/x86_64/kernel/asm-offsets.s' is up to date.
>>   CHK     include/linux/compile.h
>>   CHK     usr/initramfs_list
>>   GEN     .version
>>   CHK     include/linux/compile.h
>>   UPD     include/linux/compile.h
>>   CC      init/version.o
>>   LD      init/built-in.o
>>   LD      .tmp_vmlinux1
>> arch/xen/x86_64/kernel/built-in.o(.text+0x291): In function
>> `xen_idle':
>>> undefined reference to `set_timeout_timer'
>> make[2]: *** [.tmp_vmlinux1] Error 1
>> make[2]: Leaving directory
>> `/home/xin/bk/xeno-unstable.bk/linux-2.6.11-xen0'
>> make[1]: *** [build] Error 2
>> make[1]: Leaving directory `/home/xin/bk/xeno-unstable.bk'
>> make: *** [linux-2.6-xen0-build] Error 2
>> 
>> -Xin
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> Jun
> ---
> Intel Open Source Technology Center
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: Latest bk can NOT compile on x86_64

[Nakajima, Jun]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

Nakajima, Jun wrote:
> Nakajima, Jun wrote:
>> Actually xen itself is broken (again) too on x86-64. It dies like the
>> below. I think the breakage happened very recently (today, yesterday,
>> or the day before yesterday).
> 
> Did a quick debugging. It's failing at phys_pkg_id (it's NULL) in
> detect_ht because genacpi is not set yet when this is called. Putting
> "apic=default" makes it boot. I think it should be initialized as
> "default".   

Attached is a patch to this.

Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>

Jun
---
Intel Open Source Technology Center

[-- Attachment #2: genapic_probe.patch --]
[-- Type: application/octet-stream, Size: 811 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/05/30 23:13:49-07:00 jnakajim@los-vmm64.sc.intel.com 
#   Set genapic to genapic to apic_default as it's used before it's probled
# 
# xen/arch/x86/genapic/probe.c
#   2005/05/30 23:09:43-07:00 jnakajim@los-vmm64.sc.intel.com +1 -1
#   Set genapic to genapic to apic_default as it's used before it's probled.
# 
diff -Nru a/xen/arch/x86/genapic/probe.c b/xen/arch/x86/genapic/probe.c
--- a/xen/arch/x86/genapic/probe.c	2005-05-30 23:14:05 -07:00
+++ b/xen/arch/x86/genapic/probe.c	2005-05-30 23:14:05 -07:00
@@ -19,7 +19,7 @@
 extern struct genapic apic_es7000;
 extern struct genapic apic_default;
 
-struct genapic *genapic;
+struct genapic *genapic = &apic_default;
 
 struct genapic *apic_probe[] __initdata = { 
 	&apic_summit,

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Latest bk can NOT compile on x86_64

[Keir Fraser]

On 31 May 2005, at 07:15, Nakajima, Jun wrote:

> Did a quick debugging. It's failing at phys_pkg_id (it's NULL) in
> detect_ht because genacpi is not set yet when this is called. Putting
> "apic=default" makes it boot. I think it should be initialized as
> "default".

This one slipped through because I do not usually boot-test on an 
HT-capable system. :-) I checked in a better fix -- we were doing 
initial identify_cpu() much earlier than we needed to.

  -- Keir

RE: Latest bk can NOT compile on x86_64

[David F Barrera]

Using the latest source from BK, on x86_64 SLES 9 installation, I am
seeing this error:

gcc  -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o exec.o
monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o ide.o
ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o i8254.o pc.o
port-e9.o cirrus_vga.o libqemu.a  -lm -L../../libxc -lxc -lz   -lutil
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62:
syntax error
collect2: ld returned 1 exit status
make[5]: *** [qemu-dm] Error 1
make[5]: Leaving directory `/tmp/xen-unstable/tools/ioemu/target-i386-dm'
make[4]: *** [all] Error 1
make[4]: Leaving directory `/tmp/xen-unstable/tools/ioemu'
make[3]: *** [ioemuinstall] Error 2
make[3]: Leaving directory `/tmp/xen-unstable/tools'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/tmp/xen-unstable/tools'
make[1]: *** [tools] Error 2
make[1]: Leaving directory `/tmp/xen-unstable'
make: *** [world] Error 2

On Mon, 2005-05-30 at 23:37 -0700, Nakajima, Jun wrote:
> Nakajima, Jun wrote:
> > Nakajima, Jun wrote:
> >> Actually xen itself is broken (again) too on x86-64. It dies like the
> >> below. I think the breakage happened very recently (today, yesterday,
> >> or the day before yesterday).
> > 
> > Did a quick debugging. It's failing at phys_pkg_id (it's NULL) in
> > detect_ht because genacpi is not set yet when this is called. Putting
> > "apic=default" makes it boot. I think it should be initialized as
> > "default".   
> 
> Attached is a patch to this.
> 
> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
> 
> Jun
> ---
> Intel Open Source Technology Center
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides

Re: Latest bk can NOT compile on x86_64

[Keir Fraser]

On 31 May 2005, at 16:16, David F Barrera wrote:

> Using the latest source from BK, on x86_64 SLES 9 installation, I am
> seeing this error:
>
> gcc  -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o  
> exec.o
> monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o  
> ide.o
> ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o  
> i8254.o pc.o
> port-e9.o cirrus_vga.o libqemu.a  -lm -L../../libxc -lxc -lz   -lutil
> /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse- 
> linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62:
> syntax error

We should not have to be specially linking qemu-dm for x86/64 at all.  
The x86/32 excuse of inadequate address space to map all the foreign  
domain's pages does not hold on x86/64.

Would it break anything simply to remove the linker script for x86/64?

  -- Keir

Re: Latest bk can NOT compile on x86_64

[Scott Parish]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

The attached patch gets me past early boot.

sRp

On Tue, May 31, 2005 at 06:16:10PM +0100, Keir Fraser wrote:

> 
> On 31 May 2005, at 18:01, David F Barrera wrote:
> 
> >OK. This is the first time that I've been able to build Xen on SLES 9
> >x86_64. When attempting to boot, Dom0 crashes. Although there is 
> >already
> >a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
> >FC4, I am opening a new defect (Bugzilla #65) since the failures appear
> >different.
> 
> I wouldn't be surprised if the 32-bit PAE patch has broken guest 
> pagetable management for x86/64. I fixed a bug that caused a crash 
> during Xen bootstrap, but I didn't check domain0 booting. Lots of 
> things have changed in the dom0 builder and in arch/x86/mm.c though.
> 
>  -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

[-- Attachment #2: nx.diff --]
[-- Type: text/plain, Size: 2686 bytes --]

diff -rN -u -p old-xen-64-4/xen/arch/x86/mm.c new-xen-64-4/xen/arch/x86/mm.c
--- old-xen-64-4/xen/arch/x86/mm.c	2005-05-31 16:15:06.000000000 +0000
+++ new-xen-64-4/xen/arch/x86/mm.c	2005-05-31 16:47:32.000000000 +0000
@@ -103,6 +103,7 @@
 #include <asm/ldt.h>
 #include <asm/x86_emulate.h>
 
+#define VERBOSE 1
 #ifdef VERBOSE
 #define MEM_LOG(_f, _a...)                           \
   printk("DOM%u: (file=mm.c, line=%d) " _f "\n", \
@@ -446,7 +447,7 @@ get_page_from_l1e(
 
     if ( unlikely(l1e_get_flags(l1e) & L1_DISALLOW_MASK) )
     {
-        MEM_LOG("Bad L1 flags %x\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK);
+        MEM_LOG("Bad L1 flags %lx\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK);
         return 0;
     }
 
@@ -492,7 +493,7 @@ get_page_from_l2e(
 
     if ( unlikely((l2e_get_flags(l2e) & L2_DISALLOW_MASK)) )
     {
-        MEM_LOG("Bad L2 flags %x\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK);
+        MEM_LOG("Bad L2 flags %lx\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK);
         return 0;
     }
 
@@ -525,7 +526,7 @@ get_page_from_l3e(
 
     if ( unlikely((l3e_get_flags(l3e) & L3_DISALLOW_MASK)) )
     {
-        MEM_LOG("Bad L3 flags %x\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK);
+        MEM_LOG("Bad L3 flags %lx\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK);
         return 0;
     }
 
@@ -558,7 +559,7 @@ get_page_from_l4e(
 
     if ( unlikely((l4e_get_flags(l4e) & L4_DISALLOW_MASK)) )
     {
-        MEM_LOG("Bad L4 flags %x\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK);
+        MEM_LOG("Bad L4 flags %lx\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK);
         return 0;
     }
 
diff -rN -u -p old-xen-64-4/xen/include/asm-x86/x86_64/page.h new-xen-64-4/xen/include/asm-x86/x86_64/page.h
--- old-xen-64-4/xen/include/asm-x86/x86_64/page.h	2005-05-31 16:15:06.000000000 +0000
+++ new-xen-64-4/xen/include/asm-x86/x86_64/page.h	2005-05-31 16:50:24.000000000 +0000
@@ -61,12 +61,12 @@ typedef l4_pgentry_t root_pgentry_t;
 #define get_pte_flags(x) ((int)((x) >> 40) | ((int)(x) & 0xFFF))
 #define put_pte_flags(x) ((((intpte_t)((x) & ~0xFFF)) << 40) | ((x) & 0xFFF))
 
-#define _PAGE_NX                (cpu_has_nx ? (1U<<23) : 0U)
+#define _PAGE_NX                (cpu_has_nx ? (1UL<<63) : 0UL)
 
-#define L1_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PAT/GLOBAL */
-#define L2_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PSE/GLOBAL */
-#define L3_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */
-#define L4_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */
+#define L1_DISALLOW_MASK _PAGE_NX
+#define L2_DISALLOW_MASK _PAGE_NX
+#define L3_DISALLOW_MASK _PAGE_NX
+#define L4_DISALLOW_MASK _PAGE_NX
 
 #endif /* __X86_64_PAGE_H__ */
 


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Latest bk can NOT compile on x86_64

[Scott Parish]

Uh, this patch is completely wrong, please ignore, k thanks.

sRp

On Tue, May 31, 2005 at 04:52:09PM +0000, Scott Parish wrote:

> The attached patch gets me past early boot.
> 
> sRp
> 
> On Tue, May 31, 2005 at 06:16:10PM +0100, Keir Fraser wrote:
> 
> > 
> > On 31 May 2005, at 18:01, David F Barrera wrote:
> > 
> > >OK. This is the first time that I've been able to build Xen on SLES 9
> > >x86_64. When attempting to boot, Dom0 crashes. Although there is 
> > >already
> > >a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
> > >FC4, I am opening a new defect (Bugzilla #65) since the failures appear
> > >different.
> > 
> > I wouldn't be surprised if the 32-bit PAE patch has broken guest 
> > pagetable management for x86/64. I fixed a bug that caused a crash 
> > during Xen bootstrap, but I didn't check domain0 booting. Lots of 
> > things have changed in the dom0 builder and in arch/x86/mm.c though.
> > 
> >  -- Keir
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> 
> -- 
> Scott Parish
> Signed-off-by: srparish@us.ibm.com

> diff -rN -u -p old-xen-64-4/xen/arch/x86/mm.c new-xen-64-4/xen/arch/x86/mm.c
> --- old-xen-64-4/xen/arch/x86/mm.c	2005-05-31 16:15:06.000000000 +0000
> +++ new-xen-64-4/xen/arch/x86/mm.c	2005-05-31 16:47:32.000000000 +0000
> @@ -103,6 +103,7 @@
>  #include <asm/ldt.h>
>  #include <asm/x86_emulate.h>
>  
> +#define VERBOSE 1
>  #ifdef VERBOSE
>  #define MEM_LOG(_f, _a...)                           \
>    printk("DOM%u: (file=mm.c, line=%d) " _f "\n", \
> @@ -446,7 +447,7 @@ get_page_from_l1e(
>  
>      if ( unlikely(l1e_get_flags(l1e) & L1_DISALLOW_MASK) )
>      {
> -        MEM_LOG("Bad L1 flags %x\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK);
> +        MEM_LOG("Bad L1 flags %lx\n", l1e_get_flags(l1e) & L1_DISALLOW_MASK);
>          return 0;
>      }
>  
> @@ -492,7 +493,7 @@ get_page_from_l2e(
>  
>      if ( unlikely((l2e_get_flags(l2e) & L2_DISALLOW_MASK)) )
>      {
> -        MEM_LOG("Bad L2 flags %x\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK);
> +        MEM_LOG("Bad L2 flags %lx\n", l2e_get_flags(l2e) & L2_DISALLOW_MASK);
>          return 0;
>      }
>  
> @@ -525,7 +526,7 @@ get_page_from_l3e(
>  
>      if ( unlikely((l3e_get_flags(l3e) & L3_DISALLOW_MASK)) )
>      {
> -        MEM_LOG("Bad L3 flags %x\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK);
> +        MEM_LOG("Bad L3 flags %lx\n", l3e_get_flags(l3e) & L3_DISALLOW_MASK);
>          return 0;
>      }
>  
> @@ -558,7 +559,7 @@ get_page_from_l4e(
>  
>      if ( unlikely((l4e_get_flags(l4e) & L4_DISALLOW_MASK)) )
>      {
> -        MEM_LOG("Bad L4 flags %x\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK);
> +        MEM_LOG("Bad L4 flags %lx\n", l4e_get_flags(l4e) & L4_DISALLOW_MASK);
>          return 0;
>      }
>  
> diff -rN -u -p old-xen-64-4/xen/include/asm-x86/x86_64/page.h new-xen-64-4/xen/include/asm-x86/x86_64/page.h
> --- old-xen-64-4/xen/include/asm-x86/x86_64/page.h	2005-05-31 16:15:06.000000000 +0000
> +++ new-xen-64-4/xen/include/asm-x86/x86_64/page.h	2005-05-31 16:50:24.000000000 +0000
> @@ -61,12 +61,12 @@ typedef l4_pgentry_t root_pgentry_t;
>  #define get_pte_flags(x) ((int)((x) >> 40) | ((int)(x) & 0xFFF))
>  #define put_pte_flags(x) ((((intpte_t)((x) & ~0xFFF)) << 40) | ((x) & 0xFFF))
>  
> -#define _PAGE_NX                (cpu_has_nx ? (1U<<23) : 0U)
> +#define _PAGE_NX                (cpu_has_nx ? (1UL<<63) : 0UL)
>  
> -#define L1_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PAT/GLOBAL */
> -#define L2_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* PSE/GLOBAL */
> -#define L3_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */
> -#define L4_DISALLOW_MASK (0xFFFFF180U & ~_PAGE_NX) /* must-be-zero */
> +#define L1_DISALLOW_MASK _PAGE_NX
> +#define L2_DISALLOW_MASK _PAGE_NX
> +#define L3_DISALLOW_MASK _PAGE_NX
> +#define L4_DISALLOW_MASK _PAGE_NX
>  
>  #endif /* __X86_64_PAGE_H__ */
>  
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

Re: Latest bk can NOT compile on x86_64

[David F Barrera]

OK. This is the first time that I've been able to build Xen on SLES 9
x86_64. When attempting to boot, Dom0 crashes. Although there is already
a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
FC4, I am opening a new defect (Bugzilla #65) since the failures appear
different.
 

__  __            _____  ___         _                _
 \ \/ /___ _ __   |___ / / _ \     __| | _____   _____| |
  \  // _ \ '_ \    |_ \| | | |__ / _` |/ _ \ \ / / _ \ |
  /  \  __/ | | |  ___) | |_| |__| (_| |  __/\ V /  __/ |
 /_/\_\___|_| |_| |____(_)___/    \__,_|\___| \_/ \___|_|

 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory

 Xen version 3.0-devel (root@ltc.austin.ibm.com) (gcc version 3.3.3 (SuSE
Linux)) Tue May 31 06:20:43 CDT 2005
 Latest ChangeSet: information unavailable

(XEN) Physical RAM map:
(XEN)  0000000000000000 - 000000000009d400 (usable)
(XEN)  000000000009d400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 000000003ffbe680 (usable)
(XEN)  000000003ffbe680 - 000000003ffd0000 (ACPI data)
(XEN)  000000003ffd0000 - 0000000040000000 (reserved)
(XEN)  00000000fec00000 - 0000000100000000 (reserved)
(XEN) System RAM: 1023MB (1047916kB)
(XEN) Xen heap: 14MB (14804kB)
(XEN) found SMP MP-table at 0009d540
(XEN) DMI 2.3 present.
(XEN) Using APICSH\uffff(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
(XEN) Processor #6 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 15:4 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
(XEN) Processor #7 15:4 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
(XEN) ACPI: LAPIC_NMI
(acpi_i9\uffff\u0455\uffff\u0455\uffff5!\uffff\uffff\u027d\uffff\uffff\uffff\u037d\uffffXEN)
Using scheduler: Borrowed Virtual Time (bvt)
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU0: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
(XEN) Booting processor 1/1 eip 90000
(XEN) Initializing CPU#1
(XEN) CPU: Trace cache: 12K uops, L1 D cache: 16K
(XEN) CPU: L2 cache: 1024K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU1: Intel(R) Xeon(TM) CPU 3.60GHz stepping 01
(XEN) Booting proc
AU!\uffff\uffff\u0455\uffff\uffff\uffff\uffff\uffffXEN) Total of 4 processors
activated.
(XEN) ENABLING IO-APIC IRQs
(XEN) ..TIMER: vector=0x31 pin1=2 pin2=-1
(XEN) checking TSC synchronization across 4 CPUs: passed.
(XEN) Time init:
(XEN) .... cpu_freq:    00000000:D6980F54
(XEN) .... scale:       00000001:1C6BEB88
(XEN) .... Wall Clock:  1117540311s 180000us
(XEN) Brought up 4 CPUs
(XEN) mtrr: v2.0 (20020519)
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen-ELF header found:
'GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=3.0,VIRT_BASE=0xffffffff80100000,LOADER=generic'
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000010000000->0000000020000000 (62464 pages to be
allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff80100000->ffffffff80576086
(XEN)  Init. ramdisk: ffffffff80577000->ffffffff80577000
(XEN)  Phys-Mach map: ffffffff80577000->ffffffff805f4000
(XEN)  Page tables:   ffffffff805f4000->ffffffff805fb000
(XEN)  Start info:    ffffffff805fb000->ffffffff805fc000
(XEN)  Boot stack:    ffffffff805fc000->ffffffff805fd000
(XEN)  TOTAL:         ffffffff80000000->ffffffff80800000
(XEN)  ENTRY ADDRESS: ffffffff80100000
(XEN) Scrubbing Free RAM: ...........done.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen).
(XEN) CPU:    0
(XEN) EIP:    e030:[<0000000000000000>]
(XEN) EFLAGS: 0000000000010282
(XEN) rax: 00000000ffffffea   rbx: 00000000105f5000   rcx: 0000000000000000  
rdx: 0000000000000000
(XEN) rsi: 0000000000000001   rdi: ffffffff804ebf40   rbp: 0000000000000808  
rsp: ffffffff804ebf08
(XEN) r8:  0000000000000000   r9:  0000000000000000   r10: 0000000000007ff0  
r11: 0000000000000282
(XEN) r12: 0000000000000000   r13: ffffffff805f4000   r14: ffffffff80102000  
r15: ffffffff804ebfb0
(XEN) Xen stack trace from rsp=ffffffff804ebf08:
(XEN)    ffffffff80118d9d 0000000000000202 ffffffff80118da1 000000000001e030
0000000000010282 ffffffff804ebf40 000000000000e02b 00000000105f5808
(XEN)    0000000010101065 0000000000000000 ffffffff80115d08 0000000000000000
0000000000000000 ffffffff804d8080 ffffffff80 on CPU0:
Domain 0 crashed!
****************************************

Reboot in five seconds...
(XEN) Reboot disabled on cmdline: require manual reset

On Tue, 2005-05-31 at 16:49 +0100, Keir Fraser wrote:
> On 31 May 2005, at 16:16, David F Barrera wrote:
> 
> > Using the latest source from BK, on x86_64 SLES 9 installation, I am
> > seeing this error:
> >
> > gcc  -Wl,-T,/tmp/xen-unstable/tools/ioemu/x86_64.ld -o qemu-dm vl.o  
> > exec.o
> > monitor.o osdep.o block.o readline.o pci.o console.o block-cloop.o  
> > ide.o
> > ne2000.o pckbd.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o  
> > i8254.o pc.o
> > port-e9.o cirrus_vga.o libqemu.a  -lm -L../../libxc -lxc -lz   -lutil
> > /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse- 
> > linux/bin/ld:/tmp/xen-unstable/tools/ioemu/x86_64.ld:62:
> > syntax error
> 
> We should not have to be specially linking qemu-dm for x86/64 at all.  
> The x86/32 excuse of inadequate address space to map all the foreign  
> domain's pages does not hold on x86/64.
> 
> Would it break anything simply to remove the linker script for x86/64?
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides

Re: Latest bk can NOT compile on x86_64

[Keir Fraser]

On 31 May 2005, at 18:01, David F Barrera wrote:

> OK. This is the first time that I've been able to build Xen on SLES 9
> x86_64. When attempting to boot, Dom0 crashes. Although there is 
> already
> a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
> FC4, I am opening a new defect (Bugzilla #65) since the failures appear
> different.

I wouldn't be surprised if the 32-bit PAE patch has broken guest 
pagetable management for x86/64. I fixed a bug that caused a crash 
during Xen bootstrap, but I didn't check domain0 booting. Lots of 
things have changed in the dom0 builder and in arch/x86/mm.c though.

  -- Keir

RE: Latest bk can NOT compile on x86_64

[Nakajima, Jun]

David F Barrera wrote:
> OK. This is the first time that I've been able to build Xen on SLES 9
> x86_64. When attempting to boot, Dom0 crashes. Although there is
> already 
> a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
> FC4, I am opening a new defect (Bugzilla #65) since the failures
> appear different.
> 
> (XEN) Scrubbing Free RAM: ...........done.
> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen). (XEN) CPU:    0
> (XEN) EIP:    e030:[<0000000000000000>]
> (XEN) EFLAGS: 0000000000010282
> (XEN) rax: 00000000ffffffea   rbx: 00000000105f5000   rcx:
> 0000000000000000 
> rdx: 0000000000000000
> (XEN) rsi: 0000000000000001   rdi: ffffffff804ebf40   rbp:
> 0000000000000808 
> rsp: ffffffff804ebf08
> (XEN) r8:  0000000000000000   r9:  0000000000000000   r10:
> 0000000000007ff0 
> r11: 0000000000000282
> (XEN) r12: 0000000000000000   r13: ffffffff805f4000   r14:
> ffffffff80102000 
> r15: ffffffff804ebfb0
> (XEN) Xen stack trace from rsp=ffffffff804ebf08:
> (XEN)    ffffffff80118d9d 0000000000000202 ffffffff80118da1
> 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b
> 00000000105f5808 (XEN)    0000000010101065 0000000000000000
> ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080
> ffffffff80 on CPU0: 
> Domain 0 crashed!
> ****************************************
> 

This is different from the other ones, but we need more hints as I don't
see this problem on our machines. For example, can you show the
instructions around 0xffffffff80118d9d? Please do like
1. objdump -d vmlinux > out (in linux-2.6.11-xen0)
2. search ffffffff80118d9d in 'out'
3. cut and send the disassembled instructions around ffffffff80118d9d.

Jun
---
Intel Open Source Technology Center

RE: Latest bk can NOT compile on x86_64

[David F Barrera]

On Tue, 2005-05-31 at 12:32 -0700, Nakajima, Jun wrote:
> David F Barrera wrote:
> > OK. This is the first time that I've been able to build Xen on SLES 9
> > x86_64. When attempting to boot, Dom0 crashes. Although there is
> > already 
> > a defect open (Bugzilla #26) for a failure to boot Dom0 on x86_64 on
> > FC4, I am opening a new defect (Bugzilla #65) since the failures
> > appear different.
> > 
> > (XEN) Scrubbing Free RAM: ...........done.
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > input to Xen). (XEN) CPU:    0
> > (XEN) EIP:    e030:[<0000000000000000>]
> > (XEN) EFLAGS: 0000000000010282
> > (XEN) rax: 00000000ffffffea   rbx: 00000000105f5000   rcx:
> > 0000000000000000 
> > rdx: 0000000000000000
> > (XEN) rsi: 0000000000000001   rdi: ffffffff804ebf40   rbp:
> > 0000000000000808 
> > rsp: ffffffff804ebf08
> > (XEN) r8:  0000000000000000   r9:  0000000000000000   r10:
> > 0000000000007ff0 
> > r11: 0000000000000282
> > (XEN) r12: 0000000000000000   r13: ffffffff805f4000   r14:
> > ffffffff80102000 
> > r15: ffffffff804ebfb0
> > (XEN) Xen stack trace from rsp=ffffffff804ebf08:
> > (XEN)    ffffffff80118d9d 0000000000000202 ffffffff80118da1
> > 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b
> > 00000000105f5808 (XEN)    0000000010101065 0000000000000000
> > ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080
> > ffffffff80 on CPU0: 
> > Domain 0 crashed!
> > ****************************************
> > 
> 
> This is different from the other ones, but we need more hints as I don't
> see this problem on our machines. For example, can you show the
> instructions around 0xffffffff80118d9d? Please do like
> 1. objdump -d vmlinux > out (in linux-2.6.11-xen0)
> 2. search ffffffff80118d9d in 'out'
> 3. cut and send the disassembled instructions around ffffffff80118d9d.
OK. Here they are:(ffffffff80118d9d is in the middle)

ffffffff80118d4f:       90                      nop
ffffffff80118d50:       48 b8 00 00 00 00 00    mov    $0x780000000000,%
rax
ffffffff80118d57:       78 00 00
ffffffff80118d5a:       48 8d 0c 38             lea    (%rax,%rdi,1),%
rcx
ffffffff80118d5e:       48 8b 15 1b 15 37 00    mov    3609883(%rip),%
rdx  # ffffffff8048a280 <phys_to_machine_mapping>
ffffffff80118d65:       48 89 e7                mov    %rsp,%rdi
ffffffff80118d68:       48 89 c8                mov    %rcx,%rax
ffffffff80118d6b:       81 e1 ff 0f 00 00       and    $0xfff,%ecx
ffffffff80118d71:       48 c1 e8 0c             shr    $0xc,%rax
ffffffff80118d75:       89 c0                   mov    %eax,%eax
ffffffff80118d77:       8b 04 82                mov    (%rdx,%rax,4),%
eax
ffffffff80118d7a:       48 89 74 24 08          mov    %rsi,0x8(%rsp)
ffffffff80118d7f:       be 01 00 00 00          mov    $0x1,%esi
ffffffff80118d84:       31 d2                   xor    %edx,%edx
ffffffff80118d86:       48 c1 e0 0c             shl    $0xc,%rax
ffffffff80118d8a:       48 09 c8                or     %rcx,%rax
ffffffff80118d8d:       48 89 04 24             mov    %rax,(%rsp)
ffffffff80118d91:       48 89 f0                mov    %rsi,%rax
ffffffff80118d94:       49 c7 c2 f0 7f 00 00    mov    $0x7ff0,%r10
ffffffff80118d9b:       0f 05                   syscall

ffffffff80118d9d:       85 c0                   test   %eax,%eax

ffffffff80118d9f:       79 0f                   jns    ffffffff80118db0
<xen_l1_entry_update+0x80>
ffffffff80118da1:       0f 0b                   ud2a
ffffffff80118da3:       03 41 3a                add    0x3a(%rcx),%eax
ffffffff80118da6:       80 ff ff                cmp    $0xff,%bh
ffffffff80118da9:       ff                      (bad)
ffffffff80118daa:       ff 35 00 66 66 90       pushq  -1872337408(%rip)
# ffffffff1077f3b0 <__start___xen_guest+0xffffffff10779a52>
ffffffff80118db0:       48 83 c4 18             add    $0x18,%rsp
ffffffff80118db4:       c3                      retq
ffffffff80118db5:       66                      data16
ffffffff80118db6:       66                      data16
ffffffff80118db7:       66                      data16
ffffffff80118db8:       90                      nop
ffffffff80118db9:       66                      data16
ffffffff80118dba:       66                      data16
ffffffff80118dbb:       66                      data16
ffffffff80118dbc:       90                      nop
ffffffff80118dbd:       66                      data16
ffffffff80118dbe:       66                      data16
ffffffff80118dbf:       90                      nop

ffffffff80118dc0 <allocate_empty_lowmem_region>:
ffffffff80118dc0:       41 57                   push   %r15
ffffffff80118dc2:       48 c1 e7 0c             shl    $0xc,%rdi
ffffffff80118dc6:       48 8d 47 ff             lea
0xffffffffffffffff(%rdi),%rax
ffffffff80118dca:       41 56                   push   %r14

> 
> Jun
> ---
> Intel Open Source Technology Center
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
                                                        Euripides

RE: Latest bk can NOT compile on x86_64

[Nakajima, Jun]

David F Barrera wrote:
> On Tue, 2005-05-31 at 12:32 -0700, Nakajima, Jun wrote:
>> David F Barrera wrote:
>>> OK. This is the first time that I've been able to build Xen on SLES
>>> 9 x86_64. When attempting to boot, Dom0 crashes. Although there is
>>> already a defect open (Bugzilla #26) for a failure to boot Dom0 on
>>> x86_64 on FC4, I am opening a new defect (Bugzilla #65) since the
>>> failures appear different. 
>>> 
>>> (XEN) Scrubbing Free RAM: ...........done.
>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>>> input to Xen). (XEN) CPU:    0
>>> (XEN) EIP:    e030:[<0000000000000000>]
>>> (XEN) EFLAGS: 0000000000010282
>>> (XEN) rax: 00000000ffffffea   rbx: 00000000105f5000   rcx:
>>> 0000000000000000 rdx: 0000000000000000
>>> (XEN) rsi: 0000000000000001   rdi: ffffffff804ebf40   rbp:
>>> 0000000000000808 rsp: ffffffff804ebf08
>>> (XEN) r8:  0000000000000000   r9:  0000000000000000   r10:
>>> 0000000000007ff0 r11: 0000000000000282
>>> (XEN) r12: 0000000000000000   r13: ffffffff805f4000   r14:
>>> ffffffff80102000 r15: ffffffff804ebfb0
>>> (XEN) Xen stack trace from rsp=ffffffff804ebf08:
>>> (XEN)    ffffffff80118d9d 0000000000000202 ffffffff80118da1
>>> 000000000001e030 0000000000010282 ffffffff804ebf40 000000000000e02b
>>> 00000000105f5808 (XEN)    0000000010101065 0000000000000000
>>> ffffffff80115d08 0000000000000000 0000000000000000 ffffffff804d8080
>>> ffffffff80 on CPU0: Domain 0 crashed!
>>> ****************************************
>>> 
>> 
>> This is different from the other ones, but we need more hints as I
>> don't see this problem on our machines. For example, can you show the
>> instructions around 0xffffffff80118d9d? Please do like
>> 1. objdump -d vmlinux > out (in linux-2.6.11-xen0)
>> 2. search ffffffff80118d9d in 'out'
>> 3. cut and send the disassembled instructions around
>> ffffffff80118d9d. 
> OK. Here they are:(ffffffff80118d9d is in the middle)

Looks like xen_l1_entry_update is failing because xen did not like the
page. 

Can you do the same thing with 0xffffffff80115d08?

Jun
---
Intel Open Source Technology Center