Re: [Xen-devel] [PATCH 2 of 3] Enable UEFI BIOS(OVMF) support in Xen-unstable HVM

[Andrei Warkentin <andreiw@xxxxxxxxxxxx>]

Heya,

On Tue, Aug 9, 2011 at 9:39 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>>         What is the difference between these versions of the VGA BIOS and 
>> the existing one?
>> I am unsure what is the difference between OVMF VGA BIOS and the existing 
>> one in firmware/vgabios. Maybe Andrei or Jordan can give the answer.
>
> Yes please.
>

OVMF "VGA bios" is an EFI driver. It is a PE32 (for IA-32) or PE32+
(for X64) binary that contains a framebuffer driver written in C and
conforming to the UEFI driver model. It is 64-bit long mode code for
X64, and 32-bit pmode code for IA-32. You cannot reuse the legacy
16-bit VGA ROM.

>>
>>
>>
>>
>>         It seems like you only checking the binaries, where is the source 
>> and what is its license?
>> The source code of OVMF BIOS is available at
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/OvmfPkg/ .
>> And the license is BSD license.
>>
>>
>> Building the OVMF BIOS needs the environment edk2, whose source code is 
>> available at
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ .
>> I am afraid OVMF source code can't be downloaded and built in Xen compiling 
>> environment.
>> So, I just provide the binary files of OVMF VGA and OVMF BIOS firmware.
>
> Oh, I see.
>
> Generally we would like to avoid adding new external projects to the Xen
> source tree. Long term we would instead like to see a kind of "meta"
> build system which pulls together Xen and the various bits and pieces.
>
> In the seabios case we decided not to pull any bits seabios into
> xen.hg/tools/firmware/seabios/ but rather to provide a configuration
> variable which would point to a built seabios.git tree. I think a
> similar model would make sense for the OVMF support. IOW OVMF_DIR = ""
> by default (OVMF disabled), users who want OVMF can obtain and build
> OVMF and then set OVMF_DIR to point this built tree. (eventually this
> step  will be subsumed into the "meta" build system)

I like this.

>
>>
>>
>>
>>
>>         With SeaBIOS we moved to a model of loading option ROMs from the
>>         emulated devices themselves (via the ROM BAR). Could this be used for
>>         OVMF too?
>> Do you mean use the bios->load_roms to load OVMF VGA BIOS instead of loading 
>> it in bios_load?
>
> No. Hardware devices have a special BAR which can be used to map their
> option ROM. BIOSes (i.e. real ones on physical machines) use this in
> order to map the option ROMs and copy or run them etc. SeaBIOS also
> supports this and qemu supports emulating these BARs for the given
> devices by providing the contents of a specific file on the host file
> system and so we don't load any VGA BIOS in hvmloader in that case and
> just let seabios and qemu take care of it via this mechanism.
>
> So what I'm suggesting is that OVMF should (and possibly already does)
> support this operation and should load the VGA rom itself from the VGA
> devices ROM BAR. If the VGABIOS for OVMF needs to be different to what
> would be normally need with a legacy BIOS then we can enhance QEMU to
> provide the option to request alternative ROM images be used.
>
> This model makes sense since a device's option-ROM is tied more to the
> specific device than it is to the BIOS etc.

I think long-term this is doable and a good idea. Obviously EFI does
support loading drivers from PCI ROM, yet right now OVMF just builds
in the relevant video drivers into the firmware.
Because drivers bind only to specific hardware, it is safe to contain
all possible video drivers. I think for now we can just claim no "vga
rom" as far hvmloader is concerned.

A

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel