Re: [Xen-devel] [PATCH for-xen-4.5 v3 00/16] xen: Break multiboot (v1) dependency and add multiboot2 support

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Fri, Oct 10, 2014 at 01:25:20PM +0100, Jan Beulich wrote:
> >>> On 10.10.14 at 13:07, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Fri, Oct 10, 2014 at 09:23:55AM +0100, Jan Beulich wrote:
> >> >>> On 08.10.14 at 19:52, <daniel.kiper@xxxxxxxxxx> wrote:
> >> > Patch #13 reveals a bug which probably was introduced between commit
> >> > 3e2331d271cc0882e4013c8f20398c46c35f90a1 (VT-d: suppress UR signaling for
> >> > further desktop chipsets) and 61fdda7acf3de11f3d50d50e5b4f4ecfac7e0d04
> >> > (x86/HVM: properly bound x2APIC MSR range). Xen crashes at 
> >> > video_endboot()
> >> > because earlier scrub process wipes vga_console_info data (sic!). So,
> >> > it means that at least page containing this structure was freed 
> >> > mistakenly
> >> > somewhere. Interestingly this issue appears on legacy BIOS machines only.
> >> > EFI platforms work as usual. It is possible to workaround this bug by
> >> > passing no-bootscrub to xen.gz.
> >>
> >> Giving a little more detail on how exactly things crash would be rather
> >> useful to make suggestions. Or if you intend to figure this out all by
> >> yourself, then I think you would have better done so before posting
> >> this series.
> >
> > I am attaching console log. Xen crashes at
> > xen/drivers/video/vga.c:video_endboot():175.
> >
> >     switch ( boot_info->vga_console_info.video_type )
>
> Without your changes this line is
>
>     switch ( vga_console_info.video_type )
>
> with the variable being a global, non-_initdata one. That way it just
> can't go away unless we have some sort of memory corruption.
> Therefore I would rather think that the problem is inside your series.

I do not rule it out but... v2 which I sent previously works correctly. v3 is
just better split of v2 (with minor changes). Additonally, boot_info
points to boot_info_mb on legacy BIOS which is defined in
xen/arch/x86/boot_info.c as static boot_info_t __read_mostly boot_info_mb.

readelf -Wa xen/xen-syms shows:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg 
Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      
0   0  0
  [ 1] .text             PROGBITS        ffff82d080100000 001000 13637e 00 WAX  
0   0 4096
  [ 2] .rodata           PROGBITS        ffff82d080236380 137380 0471f0 00   A  
0   0 32
  [ 3] .data.read_mostly PROGBITS        ffff82d08027d580 17e580 00ab38 00  WA  
0   0 128
  [ 4] .data             PROGBITS        ffff82d080289000 18a000 00e3c8 00  WA  
0   0 4096
  [ 5] .discard          PROGBITS        ffff82d0802973c8 1983c8 00014e 00  WA  
0   0  1
  [ 6] .init.text        PROGBITS        ffff82d080298000 199000 032ae9 00  AX  
0   0 16
  [ 7] .init.data        PROGBITS        ffff82d0802cab00 1cbb00 011fb0 00  WA  
0   0 32
  [ 8] .init.setup       PROGBITS        ffff82d0802dcac0 1ddac0 001220 00  WA  
0   0 32
  [ 9] .initcall.init    PROGBITS        ffff82d0802ddce0 1dece0 000218 00  WA  
0   0  8
  [10] .bss              NOBITS          ffff82d0802e0000 1deef8 049e00 00  WA  
0   0 128

I thoutgh that .data.read_mostly is adjacent to .init.* section, which
would be an explanation, but it is not the case. So, what is wrong?

Daniel

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