Bug 480880 - f10 x86_64 xen guests fail to boot on f8 host (NX issue)
f10 x86_64 xen guests fail to boot on f8 host (NX issue)
Status: CLOSED DUPLICATE of bug 492523
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Fedora Extras Quality Assurance
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
Reported: 2009-01-20 21:59 EST by Naoki
Modified: 2009-04-03 07:30 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-03 07:30:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Naoki 2009-01-20 21:59:31 EST
Description of problem:
f10 x86_64 xen guests fail to boot on f8 hosts which lack the NX cpu flag.

See for logs, xen dmesg, xenctx output in an easier to read format:

Version-Release number of selected component (if applicable):
Host :
Linux xen.test #1 SMP Thu Aug 7 12:44:22 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Virsh version:
Compiled against library: libvir 0.4.4
Using library: libvir 0.4.4
Using API: Xen 3.0.1
Running hypervisor: Xen 3.1.0

Guest Kernel: 

How reproducible:

Steps to Reproduce:
1. Install f8 on a machine without NX support
2. Update f8 to newest version to avoid python-virtinst bug
3. Try to boot/install an f10 x86_64 guest
Actual results:
Guest domain crashes immediately.

Expected results:
Guest domain should boot normally.

Additional info:
Mark on Fedora-virt was able to boil it down to this:
Here's the important bits:

  1) Host kernel is, that means the hypervisor is 

  2) The guest kernel is

  3) Phill points out the faulting instruction is UD2. That just means 
     the guest kernel is hitting a BUG() assertion. See /asm-x86/bug.h:

       #define BUG()                                                   \
       do {                                                            \
               asm volatile("ud2");                                    \
               for (;;) ;                                              \
       } while (0)

   4) The backtrace shows the fault happens in set_page_prot()

   5) Jon's dmesg contains:

        (XEN) mm.c:1362:d46 Bad L1 flags 800000

That means the guest is faulting here:

static void set_page_prot(void *addr, pgprot_t prot) { ....
        if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))

because the PTE update is failing in the HV here:

static int mod_l1_entry(l1_pgentry_t *pl1e, l1_pgentry_t nl1e, 
                        unsigned long gl1mfn) { ...
        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)

Other Links:
Comment 1 Mark McLoughlin 2009-02-13 05:05:21 EST
Phill points out that he can enable NX in his BIOS with "Enable Execute Disable":


Ian Campbell posted a patch upstream:


But, I don't think the patch has been merged yet.
Comment 2 Mark McLoughlin 2009-04-03 07:30:14 EDT
Okay, #492523 is the same bug and has a bunch more info

*** This bug has been marked as a duplicate of bug 492523 ***

Note You need to log in before you can comment on or make changes to this bug.