Re: [Xen-devel] Is there any limitation on the firmware size in Xen?

[Gary Lin <glin@xxxxxxxx>]

On Thu, May 11, 2017 at 12:10:56PM +0800, Gary Lin wrote:
> On Wed, May 10, 2017 at 04:47:49PM +0100, Wei Liu wrote:
> > On Wed, May 10, 2017 at 04:39:32PM +0100, Wei Liu wrote:
> > > On Wed, May 10, 2017 at 08:29:35AM -0600, Charles Arnold wrote:
> > > > I was asked the following question which I am posting to the list.
> > > > 
> > > > "
> > > > My name is Gary Lin, and I am the maintainer of the OVMF package, a UEFI
> > > > implementation for the virtual machines.
> > > > 
> > > > Recently, I was testing an upstream patchset[*] and encountered some
> > > > problems in Xen. Maybe you can help me or give me some hints.
> > > > 
> > > > To be short, the edk2/ovmf upstream is going to increase the firmware
> > > > size from 2MB to 4MB to fulfill windows HCK, and we have to test
> > > > different types of VM to make sure the patchset really work. When I was
> > > > using the 2MB build, my Xen HVM worked as expected and showed the boot
> > > > menu. However, if I use the 4MB build, I got something like this from
> > > > "xl dmesg":
> > > > 
> > > > (d32)  - CPU0 ... 39-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... 
> > > > done.
> > > > (d32) Testing HVM environment:
> > > > (d32)  - REP INSB across page boundaries ... passed
> > > > (d32)  - GS base MSRs and SWAPGS ... passed
> > > > (d32) Passed 2 of 2 tests
> > > > (d32) Writing SMBIOS tables ...
> > > > (d32) Loading OVMF ...
> > > > (d32) no BIOS ROM image found
> > > > (d32) *** HVMLoader bug at hvmloader.c:389
> > > > (d32) *** HVMLoader crashed.
> > > > 
> > > > I tried to trace the code and found that in 
> > > > libxl__load_hvm_firmware_module()
> > > > in tools/libxl/libxl_dom.c actully loaded the file and 
> > > > add_module_to_list()
> > > > in tools/libxc/xc_dom_x86.c was loading a firmware "module" with 4194304
> > > > bytes. However, when hvmloader loaded "bios_module" with 
> > > > get_module_entry(),
> > > > modlist is NULL. It seems the firmware data was removed for some reason.
> > > > 
> > > > Here are my questions:
> > > > 
> > > > 1. Is there any limitation on the firmware size in Xen?
> > > > 
> > > 
> > > OVMF is loaded into 4GB - ovmf_size. There shouldn't be limitation in
> > > that regard. HVMloader should be happy with that address range.
> > 
> > Oh wait, it hasn't gone that far into loading OVMF.
> > 
> > IT would be useful, as a starting point, to go through modlist, print
> > out and compare module loading addresses and lengths from both libxc and
> > hvmloader.
> > 
> 
> I printed the address and contents of hvm_start_info in get_module_entry().
> Here is the result.
> 
> 4MB build:
> 
> (d39) get_module_entry info 0x588000
> (d39) info->magic         0x0
> (d39) info->version       0x0
> (d39) info->flags         0x0
> (d39) info->nr_modules    0x0
> (d39) info->modlist_paddr 0x0
> (d39) info->cmdline_paddr 0x0
> (d39) info->rsdp_paddr    0x0
> 
> Obviously, it's corrupted since magic is 0.
> 

In the end of bootlate_hvm() (before munmap(start_info, start_info_size)):

bootlate_hvm start_info->magic 336ec578
bootlate_hvm start_info->nr_modules 1
bootlate_hvm start_info->modlist_paddr 0x588028

So until bootlate_hvm(), it seems alright.

Cheers,

Gary Lin

> 2MB build:
> 
> (d40) get_module_entry info 0x388000
> (d40) info->magic         0x336ec578
> (d40) info->version       0x0
> (d40) info->flags         0x0
> (d40) info->nr_modules    0x1
> (d40) info->modlist_paddr 0x388028
> (d40) info->cmdline_paddr 0x0
> (d40) info->rsdp_paddr    0x0
> 
> This looks alright and grub2 menu showed.
> 
> It seems the starting address increased 2MB, and I wonder if this
> matters.
> 
> Thanks,
> 
> Gary Lin

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