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

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



On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote:
> >>> On 11.05.17 at 06:10, <GLin@xxxxxxxx> 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.
> 
> Note that hvmloader's main() has
> 
>     BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
> 
> very early, so you having got past this means the corruption
> occurred inside hvmloader (or at least while it was already
> running). Could you comment out the call to perform_tests()
> and try again?
> 
You got it. After commenting out perform_tests(), the grub2 menu showed
and the system booted.

It seems that perform_tests() cleared 0x400000~0x800000, and that's why 
the members of hvm_start_info became 0 in my test.

Thanks!

Gary Lin


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

 


Rackspace

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