[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [fedora-virt] f10 x86_64 xen VM guests fail to boot on f8 host (guest setting NX bit in L1 PTE?)


I can confirm this. With NX enabled in BIOS the domU boots fine (tested with 2.6.28).

If I disable NX in BIOS the domU will crash.

- Valtteri Kiviniemi

Virtualization kirjoitti:
Hi Ian,

Indeed nx is on one and not the other! However, that doesn't help...

Broken CPU:
model name      :                   Intel(R) Xeon(TM) CPU 3.00GHz
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc up pni monitor ds_cpl cid cx16 xtpr

Good CPU:
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch

So, ran it again with noexec=0,

  [ Minimal BASH-like line editing is supported.
    ESC at any time cancels.  ENTER at any time accepts your changes. ]

  > kernel /vmlinuz- ro root=LABEL=/ selinux=0 noipv6 nomodeset noexec=off


[ root office64 xen ]# /usr/lib64/xen/bin/xenctx -s System.map- 119
rip: ffffffff8100b8a2 set_page_prot+0x6d
rsp: ffffffff81575f08
rax: ffffffea   rbx: 000016e4   rcx: 00000055   rdx: 00000000
rsi: 800000014a293061   rdi: ffffffff816e4000   rbp: ffffffff81575f68
 r8: 0000000f    r9: ffffffff817ee350   r10: ffffffff817ee550   r11: 00000010
r12: ffffffff816e4000   r13: 800000014a293061   r14: 8000000000000161   r15: 00002c00
 cs: 0000e033    ds: 00000000    fs: 00000000    gs: 00000000

 0000000000000055 0000000000000010 ffffffff8100b8a2 000000010000e030
 0000000000010082 ffffffff81575f48 000000000000e02b ffffffff8100b89e
 0000000000000200 ffffffff816e7000 0000000000000800 0000000000000016
 ffffffff81575ff8 ffffffff815a5c60 0000000000002c00 0000000000000000

df 54 1d 00 4c 89 e7 4c 89 ee 31 d2 e8 22 d9 ff ff 85 c0 74 04 <0f> 0b eb fe 5b 41 5c 41 5d 41 5e

Call Trace:
  [<ffffffff8100b8a2>] set_page_prot+0x6d <--
  [<ffffffff8100b8a2>] set_page_prot+0x6d
  [<ffffffff8100b89e>] set_page_prot+0x69
  [<ffffffff815a5c60>] xen_start_kernel+0x5dd

Battling with bugzilla trying to get a new account. It doesn't like me :-(

Might have to leave it up to Jon to do the bugzilla thing.


On Tue, 2009-01-20 at 17:03 +0000, Ian Campbell wrote:
(resending with original xen-devel thread participants on CC, please
reply to this subthread, I'll forward you guys Mark's original mail in a

On Tue, 2009-01-20 at 10:27 +0000, Mark McLoughlin wrote:
       if ( unlikely(l1e_get_flags(nl1e) & L1_DISALLOW_MASK) )
            MEM_LOG("Bad L1 flags %x",
                    l1e_get_flags(nl1e) & L1_DISALLOW_MASK);
            return 0;

the PTE flags are 800000 which corresponds to:

#define _PAGE_NX_BIT (1U<<23)
At least in xen-unstable (and I think for much longer) L1_DISALLOW_MASK
contains _PAGE_NX_BIT dynamically depending on the processor

        #define _PAGE_NX     (cpu_has_nx ? _PAGE_NX_BIT : 0)
         * Disallow unused flag bits plus PAT/PSE, PCD, PWT and GLOBAL.
         * Permit the NX bit if the hardware supports it.
        #define BASE_DISALLOW_MASK (0xFFFFF198U & ~_PAGE_NX)

Does the hardware support NX? What does /proc/cpuinfo in dom0 think?

The guest kernel should be setting up __supported_pte_mask appropriately
to match the hardware and hence shouldn't be using NX if it isn't
available. There's a command line option to force NX, can you try
noexec=off on the guest command line.

My guess would be that the guest is getting a wrong EFER from


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]