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

Re: [Xen-devel] strange behavior with Multiboot2 on EFI

On Fri, Jun 22, 2018 at 05:32:39PM +0300, Kristaps Čivkulis wrote:
> What I did so far:
> Installed Arch Linux inside of Qemu virtual machine.
> Inside of virtual machine I added these lines to /etc/default/grub
> GRUB_TERMINAL="serial"
> GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no 
> --stop=1"

I would suggest that you use 115200 instead of 9600. Probably
it does not matter a lot here but on real hardware 9600 sucks.

> and called grub-mkconfig -o /boot/grub/grub.cfg
> Now when I boot my virtual machine the Grub2 uses serial console.


> I mounted EFI partition of virtual machine and copied into it Xen
> kernel with multiboot2 support, and added following lines to
> /mountpoint/grub/grub.cfg
> menuentry 'Xen kernel' {
>         set root='(hd0,1)'
>         multiboot2 /xen

I think that you should add at least this to Xen command line:
  dom0_mem=1g,max:1g guest_loglvl=all loglvl=all sync_console com1=115200,8n1 

And what about dom0 kernel? module2?

> }
> Now I am ready to launch Xen kernel inside my virtual machine.
> I launch virtual machine with following command:
> sudo qemu-system-x86_64 \
>        -hda linux.img \
>        -bios OVMF-pure-efi.fd \
>        -m 4096 \
>        -debugcon file:debug.log -global isa-debugcon.iobase=0x402

You are missing at least serial console and GDB setup. I would suggest
that you add to the QEMU command line at least this:
  -serial telnet::10232,server,nowait -gdb tcp::10234

> After choosing Xen kernel entry the following output goes to serial console:
> error: no suitable video mode found.
> Here is the tail of debug.log file:
>  [Bds]Booting GRUB
>  FSOpen: Open '\EFI\GRUB\grubx64.efi' Success
>  [Bds] Expand 
> HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRUB\grubx64.efi
> -> 
> PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRU
>      BBY\grubx64.efi
>  [Security] 3rd party image[0] can be loaded after EndOfDxe:
> PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRUB\grubx64.efi.
>  InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BF2216C0
>  Loading driver at 0x000BE5CF000 EntryPoint=0x000BE5CF400
>  InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BF29B518
>  ProtectUefiImageCommon - 0xBF2216C0
>    - 0x00000000BE5CF000 - 0x000000000001DC00
> /home/jenkins/workspace/edk2/rpms/build/edk2-gc2d6e2bc12/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c(4773):
> CR has Bad Signature

Tail of debug.log does not help a lot here. Please send us full logs
if it is needed.

> Qemu version is fresh enough:
> $ qemu-system-x86_64 --version
> QEMU emulator version 2.12.0
> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
> I tried to debug Qemu and it didn't even break in 0x3fd05e, the entry

Is this address after relocation or not? I think that the later. This will
not work. First of all please add this command to the grub.cfg:
  set debug=multiboot_loader

Then after multiboot2 call you will see something like that:
  loader/multiboot_mbi2.c:318: link_base_addr=0x200000,
  load_base_addr=0x7da00000, load_size=0x3c1000,
  loader/multiboot_mbi2.c:322: align=0x200000, preference=0x2,

Hence, you are able to get load offset using link_base_addr and load_base_addr.
Then add load offset to the multiboot2 UEFI entry point. After that set 
using "hb" in GDB (hardware assisted breakpoint). Do not use "b". IIRC it is
software breakpoint (int 3) and it will not work here because the int 3 opcode
is overwritten by the GRUB2 during final Xen code relocation. In general I 
you to use "hb". It is more reliable.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.