[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 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?

Jan


_______________________________________________
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®.