Re: [Xen-devel] [PATCH 5/5] hvmloader: Use iPXE ROM loaded from a standalone file

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/03/18 11:26, Jan Beulich wrote:
>>>> On 15.03.18 at 18:31, <anoob.soman@xxxxxxxxxx> wrote:
>> --- a/tools/firmware/hvmloader/config.h
>> +++ b/tools/firmware/hvmloader/config.h
>> @@ -33,6 +33,11 @@ struct bios_config {
>>      void (*create_mp_tables)(void);
>>      void (*create_smbios_tables)(void);
>>      void (*create_pir_tables)(void);
>> +
>> +    /* Physical address of iPXE ROM, loaded by domain builder
>> +     * when using ROMBIOS
>> +     */
>> +    unsigned int *ipxe_rom_addresss;
> Comment style. And can the pointer be to const?
>
>> @@ -368,7 +370,12 @@ int main(void)
>>  #ifdef ENABLE_ROMBIOS
>>      else if ( bios == &rombios_config )
>>      {
>> -        bios->bios_load(bios, NULL, 0);
>> +        ipxe_module = get_module_entry(hvm_start_info, "ipxe");
>> +
>> +        if ( ipxe_module )
>> +            ipxe_rom_addresss = ipxe_module->paddr;
>> +
>> +        bios->bios_load(bios, (void *)ipxe_rom_addresss, 0);
>>      }
>>  #endif
> Considering the #ifdef around here - is this whole series an
> enhancement for qemu-trad only? I don't think we mean to make
> any such enhancements anymore.

It is for several important reasons, including allowing distros to
remove their qemu-trad packages completely.


The main purpose is to have iPXE as a ROM not embedded in hvmloader, and
finishes some incomplete earlier work by Anthony to split the SeaBIOS
and OVMF roms out of HVMLoader (and then later some work which Boris
offered to do, but time hasn't materialised yet).

This means that distros don't need to rebuild and redeploy their Xen
packages every time they want to change their iPXE package and/or don't
need to maintain multiple iPXE packages.

It also removes the final non-stubdom bit of the build which downloads a
random tarball from the web, which is something downstreams have been
crying out for for years.

As for the Qemu side of things, RomBIOS functions perfectly well with
qemu-upstream, and is the only viable transition mechanism available for
downstreams wishing to purge themselves of qemu-trad entirely, while
keeping older VMs working.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel