Re: [SeaBIOS] Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Gerd Hoffmann wrote:
-kernel didn't work on a quick test.
Thinking about how to fix this, we have two options. The first would be to use the support in SeaBIOS for static roms but that would limit us to two user supplied option roms (including kernel/multiboot/extboot). We could extend this to more than two roms but I think that's generally ugly.
Alternatively, we could introduce a special rom-only PCI device. Besides getting support for a much greater number of option roms, it also gives us a much nicer way to integrate multiboot/linux boot support via qdev (instead of the ugly machine hack we have now).
We could make them multifunction devices so that we don't unnecessarily burn PCI slots to support roms.
Regards,
Anthony Liguori
cheers, Gerd
On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
Gerd Hoffmann wrote:
-kernel didn't work on a quick test.
Thinking about how to fix this, we have two options.
Hmm, can you pls explain why it stops working?
The first would be to use the support in SeaBIOS for static roms but that would limit us to two user supplied option roms (including kernel/multiboot/extboot). We could extend this to more than two roms but I think that's generally ugly.
Alternatively, we could introduce a special rom-only PCI device. Besides getting support for a much greater number of option roms, it also gives us a much nicer way to integrate multiboot/linux boot support via qdev (instead of the ugly machine hack we have now).
We could make them multifunction devices so that we don't unnecessarily burn PCI slots to support roms.
Regards,
Anthony Liguori
cheers, Gerd
Will be a problem for non-PCI systems?
Michael S. Tsirkin wrote:
On Tue, Dec 15, 2009 at 01:35:52PM -0600, Anthony Liguori wrote:
Gerd Hoffmann wrote:
-kernel didn't work on a quick test.
Thinking about how to fix this, we have two options.
Hmm, can you pls explain why it stops working?
Sure. SeaBIOS loads roms in a few ways.
If CONFIG_OPTIONROMS_DEPLOYED, then SeaBIOS scans the 0xc0000..0xf0000 region for anything that looks like a rom. This is how Bochs did it and is what qemu supports. This is not how modern systems work though.
Modern systems (SeaBIOS with !CONFIG_OPTIONROMS_DEPLOYED), walk the PCI bus and look for any device with a PCI_ROM_ADDRESS that maps a valid option rom. It will map the rom in PCI memory and run it's init function. The rom can use PMM to allocate temporary memory to reorganize itself. During this time, the rom area is writable. The rom will create a stub that's usually pretty small that gets loaded by the BIOS after init into the 0xc0000..0xf0000 region.
So when !CONFIG_OPTIONROMS_DEPLOYED, SeaBIOS does look in this region for roms because it maps them all from the actual PCI devices.
SeaBIOS can also load roms from up to two fixed physical addresses (when !CONFIG_OPTIONROMS_DEPLOYED) or from a CBFS payload.
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests. In fact, it should Just Work with my patches !CONFIG_OPTIONROMS_DEPLOYED in SeaBIOS.
Regards,
Anthony Liguori
cheers, Gerd
Will be a problem for non-PCI systems?
You mean, non-PCI x86 systems? I think -m isapc is mainly used for dos guests. I don't think it's really useful in combination with -kernel and certainly not for extboot.
Regards,
Anthony Liguori
* Anthony Liguori (anthony@codemonkey.ws) wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests.
I think so too.
In fact, it should Just Work with my patches !CONFIG_OPTIONROMS_DEPLOYED in SeaBIOS.
What would be the magic to boot from that ROM?
thanks, -chris
Chris Wright wrote:
- Anthony Liguori (anthony@codemonkey.ws) wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests.
I think so too.
In fact, it should Just Work with my patches !CONFIG_OPTIONROMS_DEPLOYED in SeaBIOS.
What would be the magic to boot from that ROM?
Setup device assignment, add -boot menu=on with my patches, and hit F12 when prompted. In theory, you should see an entry for the device.
If not, the output with DEBUG_BIOS enabled in hw/pc.c would be very interesting.
Regards,
Anthony Liguori
On Tue, Dec 15, 2009 at 03:41:02PM -0600, Anthony Liguori wrote:
SeaBIOS can also load roms from up to two fixed physical addresses (when !CONFIG_OPTIONROMS_DEPLOYED) or from a CBFS payload.
The support for loading of two static option roms wont work well for qemu - it requires compiling into SeaBIOS the PCI ids of the roms.
The CBFS payload loading is closer to what qemu wants. Basically, CBFS (coreboot filesystem) is a mechanism that coreboot uses for storing named files in flash. Code to mix PCI bar roms with other roms is something SeaBIOS already handles with the CBFS system. I doubt it would be worthwhile to introduce CBFS to qemu, but I think adding a "named file" interface to qemu cfg would help.
That way, SeaBIOS could load roms from the PCI bar, CBFS, or qemu cfg without having to duplicate the logic.
This came up before in the discussion at:
http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01200.html
Right now, qemu cfg uses two ports - a file select port (0x510) and a data port (0x511). Perhaps two new ports could be added - a file name port (0x0512) and a file length port (0x513).
Basically, if there is some way for SeaBIOS to walk a list of "files" in the "qemu cfg" space, then it should be straight forward to enhance the existing code in seabios to extract and deploy roms in addition to those found in the PCI bar.
You mean, non-PCI x86 systems? I think -m isapc is mainly used for dos guests. I don't think it's really useful in combination with -kernel and certainly not for extboot.
I think the issue here is that a "-m isapc" machine wont be able to run the vga rom if the vga rom is only available from a pci bar.
-Kevin
Hi,
Basically, if there is some way for SeaBIOS to walk a list of "files" in the "qemu cfg" space, then it should be straight forward to enhance the existing code in seabios to extract and deploy roms in addition to those found in the PCI bar.
I think using fw_config is the only sane way to make it work, especially in case we switch vga bios load to pci bar too.
base address for vga bios is 0xc0000 base address for option roms is 0xc8000
If the vga bios is larger than 0x08000 bytes then the first option rom has to be loaded at a higher address. Which is actually the case, check 'info roms':
addr=00000000000c0000 size=0x008c00 mem=ram name="vgabios-cirrus.bin" addr=00000000000c9000 size=0x00dc00 mem=ram name="pxe-virtio.bin" addr=00000000fffe0000 size=0x020000 mem=rom name="bios.bin"
Thus having qemu load -- say -- linuxboot.bin and seabios load vgabios-cirrus.bin and pxe-virtio.bin simply isn't going to work. qemu has no idea what address linuxboot.bin can be loaded at (without introducing dirty hacks).
cheers, Gerd
Right now, qemu cfg uses two ports - a file select port (0x510) and a data port (0x511). Perhaps two new ports could be added - a file name port (0x0512) and a file length port (0x513).
Basically, if there is some way for SeaBIOS to walk a list of "files" in the "qemu cfg" space, then it should be straight forward to enhance the existing code in seabios to extract and deploy roms in addition to those found in the PCI bar.
What information does seabios need?
It probably needs to know whenever the rom in question is the vga bios or an option rom.
It probably also wants to get the vga bios first I assume?
Is a (file) name needed?
Would seabios load the option roms one by one or all in one go?
I'd tend to have one fw_cfg entry which returns structed data, like this:
struct fw_files { u32 filecount; struct fw_file { u32 type; /* vga, option, other? */ u32 size; /* file size */ u32 select; /* write this to 0x510 to read it */ u32 reserved; /* you never know ;) */ char name[16]; /* maybe: filename */ }; };
What do you think?
cheers, Gerd
On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote:
Right now, qemu cfg uses two ports - a file select port (0x510) and a data port (0x511). Perhaps two new ports could be added - a file name port (0x0512) and a file length port (0x513).
Basically, if there is some way for SeaBIOS to walk a list of "files" in the "qemu cfg" space, then it should be straight forward to enhance the existing code in seabios to extract and deploy roms in addition to those found in the PCI bar.
What information does seabios need?
It probably needs to know whenever the rom in question is the vga bios or an option rom.
It probably also wants to get the vga bios first I assume?
The current "CBFS" mechanism looks for named "files" of the following form:
- pciVVVV,DDDD.rom - a rom associated with a PCI device with the given vendor and device id.
- vgaroms/* - any "file" starting with the "vgaroms/" prefix is treated as a vga option rom not associated with any specific pci device.
- genroms/* - any "file" starting with the "genroms/" prefix is treated as a generic option rom not associated with any specific pci device.
The deployment order is: find the PCI vga device and look for a corresponding "pciVVVV,DDDD.rom" file or a PCI bar for it, deploy any "vgaroms/*" roms, iterate through all non-vga PCI devices and deploy their corresponding "pciVVVV,DDDD.rom" or PCI bar roms, deploy any "genroms/*" roms.
When SeaBIOS deploys a rom that is associated with a specific PCI device (either "pciVVVV,DDDD.rom" or PCI bar), it passes the PCI location as a parameter to the rom (as is required in the PCI firmware spec). Roms not associated with a device (genroms/*, vgaroms/*, and when CONFIG_OPTIONROMS_DEPLOYED) don't pass in the PCI id, so they have a slightly different calling convention.
Is a (file) name needed?
Associating a name to the fw_cfg entries and using the naming convention above would allow SeaBIOS to reuse its existing code. It seems to me that both coreboot and qemu are trying to solve the same problem, so using the same mechanism seems advantageous.
BTW, my preference would be to assign a name to all fw_cfg entries; even the existing ones.
Would seabios load the option roms one by one or all in one go?
One by one - so it can satisfy the requirement of passing the PCI location as a parameter to roms that may need that while still handling roms not associated with a device (eg, kvm's vbios, the -kernel rom, etc.).
I'd tend to have one fw_cfg entry which returns structed data, like this:
struct fw_files { u32 filecount; struct fw_file { u32 type; /* vga, option, other? */ u32 size; /* file size */ u32 select; /* write this to 0x510 to read it */ u32 reserved; /* you never know ;) */ char name[16]; /* maybe: filename */ }; };
What do you think?
It works for me. The name would need to be larger (64 bytes?). The current scheme essentially encodes 'type' into the name, so it wouldn't be needed.
-Kevin
On 12/17/09 02:24, Kevin O'Connor wrote:
On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote: The current "CBFS" mechanism looks for named "files" of the following form:
- pciVVVV,DDDD.rom - a rom associated with a PCI device with the given vendor and device id.
Might be useful for backward compatibility with older qemu versions as adding a rom bar to the pci devices is a guest-visible change in pci config space.
- vgaroms/* - any "file" starting with the "vgaroms/" prefix is treated as a vga option rom not associated with any specific pci device.
obvious place for vgabios.
- genroms/* - any "file" starting with the "genroms/" prefix is treated as a generic option rom not associated with any specific pci device.
and this for the non-pci roms like extboot &
Associating a name to the fw_cfg entries and using the naming convention above would allow SeaBIOS to reuse its existing code.
Ok.
I'd tend to have one fw_cfg entry which returns structed data, like this:
struct fw_files { u32 filecount; struct fw_file { u32 type; /* vga, option, other? */ u32 size; /* file size */ u32 select; /* write this to 0x510 to read it */ u32 reserved; /* you never know ;) */ char name[16]; /* maybe: filename */ }; };
What do you think?
It works for me. The name would need to be larger (64 bytes?).
I'd size name so it pads the struct to 32 or 64 bytes total. 32bit size, 16bit select, 16bit reserved, leaves 24 bytes for the name with 32 bytes. Hmm, better to go for a 64 byte struct, leaving 56 bytes for the name, which should be enougth.
I'll have patches ready later today.
cheers, Gerd
On Thu, Dec 17, 2009 at 10:45:45AM +0100, Gerd Hoffmann wrote:
On 12/17/09 02:24, Kevin O'Connor wrote:
On Wed, Dec 16, 2009 at 05:22:41PM +0100, Gerd Hoffmann wrote: The current "CBFS" mechanism looks for named "files" of the following form:
- pciVVVV,DDDD.rom - a rom associated with a PCI device with the given vendor and device id.
Might be useful for backward compatibility with older qemu versions as adding a rom bar to the pci devices is a guest-visible change in pci config space.
- vgaroms/* - any "file" starting with the "vgaroms/" prefix is treated as a vga option rom not associated with any specific pci device.
obvious place for vgabios.
- genroms/* - any "file" starting with the "genroms/" prefix is treated as a generic option rom not associated with any specific pci device.
and this for the non-pci roms like extboot &
Associating a name to the fw_cfg entries and using the naming convention above would allow SeaBIOS to reuse its existing code.
Ok.
I'd tend to have one fw_cfg entry which returns structed data, like this:
struct fw_files { u32 filecount; struct fw_file { u32 type; /* vga, option, other? */ u32 size; /* file size */ u32 select; /* write this to 0x510 to read it */ u32 reserved; /* you never know ;) */ char name[16]; /* maybe: filename */
Can't name simply be null terminated?
}; };
What do you think?
It works for me. The name would need to be larger (64 bytes?).
I'd size name so it pads the struct to 32 or 64 bytes total. 32bit size, 16bit select, 16bit reserved, leaves 24 bytes for the name with 32 bytes. Hmm, better to go for a 64 byte struct, leaving 56 bytes for the name, which should be enougth.
I'll have patches ready later today.
cheers, Gerd
struct fw_files { u32 filecount; struct fw_file { u32 type; /* vga, option, other? */ u32 size; /* file size */ u32 select; /* write this to 0x510 to read it */ u32 reserved; /* you never know ;) */ char name[16]; /* maybe: filename */
Can't name simply be null terminated?
It can, but it wouldn't be simple ...
cheers, Gerd
On 12/15/09 22:41, Anthony Liguori wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests.
Well, qemu-kvm has quite some code to poke the rom out of /proc/bus/pci and feed it into the rom loader. All this can simply be dropped then.
cheers Gerd
On Wed, Dec 16, 2009 at 03:41:22PM +0100, Gerd Hoffmann wrote:
On 12/15/09 22:41, Anthony Liguori wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests.
Well, qemu-kvm has quite some code to poke the rom out of /proc/bus/pci and feed it into the rom loader. All this can simply be dropped then.
cheers Gerd
It's probably safer not to assume that guest does not run the rom directly.
On Wed, Dec 16, 2009 at 04:41:33PM +0200, Michael S. Tsirkin wrote:
On Wed, Dec 16, 2009 at 03:41:22PM +0100, Gerd Hoffmann wrote:
On 12/15/09 22:41, Anthony Liguori wrote:
BTW, I'm pretty sure this style of option rom loading (from a PCI device) is going to be required for device passthrough if we want to support running those roms in the guests.
Well, qemu-kvm has quite some code to poke the rom out of /proc/bus/pci and feed it into the rom loader. All this can simply be dropped then.
cheers Gerd
It's probably safer not to assume that guest does not run the rom directly.
Directly from PCI ROM? Is this even possible?
-- Gleb.
-
Anthony Liguori -
Chris Wright -
Gerd Hoffmann -
Gleb Natapov -
Kevin O'Connor -
Michael S. Tsirkin