Re: [Xen-devel] Xen-4.3 and -unstable regression from changeset "numa-sched: leave node-affinity alone if not in 'auto' mode"

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.12.13 at 15:01, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> After some more investigation, this is not a regression at all, although
> the patch is directly relevant to identifying the problem.
> 
> PXELINUX 4.04 2011-04-18  Copyright (C) 1994-2011 H. Peter Anvin et al
> boot:
> Loading xenrt/xen-minnow.gz... ok
> Loading xenrt/vmlinuz... ok
> After multiboot magic check
> Opcode from 0x105fef: 97 0e 00 00 49 8d be b0
> Before lret into trampoline
> Opcode from 0x105fef: 97 0e 00 00 49 8d be b0
> After (failed) conditional jmp to start_secondary
> Opcode from 0xffff830000105fef: 97 0e 86 00 49 8d be b0
>  __  __            _  _    _____  _
>  \ \/ /___ _ __   | || |  |___ / / |
>   \  // _ \ '_ \  | || |_   |_ \ | |
> 
> 
> Something between entering the trampoline and emerging in 64bit mode is
> corrupting a single byte at phys 0x105ff1 from its correct value to a
> value of 0x86.
> 
> The corruption disappears if the "no-real-mode" is used.

And I'd say the primary suspect is

        /*
         * Declare that our target operating mode is long mode.
         * Initialise 32-bit registers since some buggy BIOSes depend on it.
         */
        movl    $0xec00,%eax      # declare target operating mode
        movl    $0x0002,%ebx      # long mode
        int     $0x15

considering that 0x86 is a relatively common "function not
implemented" indicator for BIOS, namely INT 15, functions.

As a possible workaround I'd consider trying
a) zeroing %esp rather than just %sp a few lines up from the
above quoted code
b) zeroing the high halves of all registers

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel