On Tue, Aug 9, 2011 at 15:35, Andrei Warkentin <andreiw@xxxxxxxxxxxx> wrote:
> On Tue, Aug 9, 2011 at 9:39 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
> wrote:
>> 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.
Actually, we don't include the video drivers in the main firmware
image. For qemu, vgabios.bin is loaded into RAM at 0xc0000, and we
find it there.
I think qemu may be moving towards loading vgabios.bin into the PCI
ROM-BAR, or maybe they already do.
Anyway, it would be best to load the video rom from the PCI device if
Xen supports it already.
-Jordan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home