[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |