RE: [Xen-devel] Cs/ 14346 breaks 64bit hv

["Woller, Thomas" <thomas.woller@xxxxxxx>]

Initial email was incorrect.  The issue is not with c/s 14346 but with
14345.  c/s 14344 is able to boot pae/64b HVM AMD-V guests on AMD-V
without issue, while c/s 14345 fails.

[snip from 14345 changeset]
 #endif
-  /* Debugging info */
-  printf("Booting from %x:%x\n", bootseg, bootip);
   
   /* Jump to the boot vector */
 ASM_START
[end code snippet]

Removing the printf causes pae and 64bit HVM AMD-V guests to fail to
boot on 64bit hypervisor.
If I add just the single "printf" line back into the rombios.c file,
then guests boot without issues.
Very strange!  
Tested with only changing the hvmloader, starting with an installed
14344 base, and used the 14345 hvmloader, result is grub failure.


Took a look at the rombios.s code generated in both cases (14344 and
14345) and seems like the "jump to the boot vector" code is not executed
on the failing case.  There is a "default: return" in the function
immediately above an "#if BX_TCGBIOS", and then the non-executed asm
code. 
Is bcc not understanding that the asm code following should be executed?
Seems like there is added a default "return" so that the "jump to boot
vector" code is never executed?  appears to be the case..but not sure.  
Code snippets are below.  Using gcc 3.3.5, but will try 4.x compiler,
although looks like bcc is used to generate the rombios.s file if I read
the Makefile correctly.

Any thoughts appreciated.

[code from rombios.c]
  default: return;
  }

#if BX_TCGBIOS
  tcpa_ipl((Bit32u)bootseg);               /* specs: 8.2.3 steps 4 and 5
*/
#endif
/* 14345 removes this: printf("Booting from %x:%x\n", bootseg, bootip);
*/
  
  /* Jump to the boot vector */
ASM_START
    mov  bp, sp
    ;; Build an iret stack frame that will take us to the boot vector.
    ;; iret pops ip, then cs, then flags, so push them in the opposite
order.
    pushf
    mov  ax, _int18_function.bootseg + 0[bp] 
    push ax
    mov  ax, _int18_function.bootip + 0[bp] 
    push ax

[code from 14344 that boots ]
push    -$A[bp]
push    -8[bp]
mov     bx,#.668
push    bx
mov     ax,*2
push    ax
call    _bios_printf
add     sp,*8
! 6170 
! 6171 
! 6172  #asm
!BCC_ASM
_int18_function.bootip  set     $12
_int18_function.seq_nr  set     $20
_int18_function.bootchk set     $16
_int18_function.bootseg set     $14
_int18_function.ebda_seg        set     $1A
_int18_function.status  set     $10
_int18_function.bootdrv set     $17
_int18_function.bootdev set     $18
_int18_function.e       set     0
    mov bp, sp
    ;; Build an iret stack frame that will take us to the boot vector.
    ;; iret pops ip, then cs, then flags, so push them in the opposite
order.
    pushf
    mov ax, _int18_function.bootseg + 0[bp]
    push ax
    mov ax, _int18_function.bootip + 0[bp]


[code from 14345 that does not boot ]
mov     -$A[bp],ax
! 6161     break;
jmp .654
! 6162 
! 6163   default: return;
.667:
mov     sp,bp
pop     bp
ret
! 6164   }
! 6165 
! 6166 
! 6167 
! 6168 
! 6169 
! 6170 
! 6171 
! 6172  #asm
!BCC_ASM
_int18_function.bootip  set     $12
_int18_function.seq_nr  set     $20
_int18_function.bootchk set     $16
_int18_function.bootseg set     $14
_int18_function.ebda_seg        set     $1A
_int18_function.status  set     $10
_int18_function.bootdrv set     $17
_int18_function.bootdev set     $18
_int18_function.e       set     0
    mov bp, sp
    ;; Build an iret stack frame that will take us to the boot vector.
    ;; iret pops ip, then cs, then flags, so push them in the opposite
order.
    pushf
    mov ax, _int18_function.bootseg + 0[bp]
    push ax
    mov ax, _int18_function.bootip + 0[bp]
    push ax


tom

 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Woller, Thomas
> Sent: Tuesday, March 13, 2007 6:01 PM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] Cs/ 14346 breaks 64bit hv
> 
> Hi Keir,
> Appears as if c/s 14346 has broken booting pae and 64bit HVM 
> linux guests, on 64bit hv on AMD-V.  
> 
> Seems like grub can't find a bootable device, and errors out.
> 
> We haven't tried VT boxes at this point.  We just uncovered 
> this issue and will investigate more.  Looks like 32bit 
> hypervisor works ok, but haven't tested thoroughly.
> 
> We'll look at the patch, but if you have any thoughts. 
> Appreciate taking a closer look at the modification.
> 
>   --Tom
> 
> thomas.woller@xxxxxxx
> AMD Corporation
> 5204 E. Ben White Blvd. UBC1
> Austin, Texas 78741
> +1-512-602-0059
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



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