[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. Great! > 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 console=com1,vga 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 > ASSERT > /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, relocatable=1 loader/multiboot_mbi2.c:322: align=0x200000, preference=0x2, avoid_efi_boot_services=1 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 breakpoint 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 suggest you to use "hb". It is more reliable. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |