It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
This patch makes seabios continue searching the pci range looking for vga cards, even if it finds one. The first card to be found is assigned to VGAbdf, being the main one. The others, just have their initializatiom roms called and are listed in the pci bus.
Signed-off-by: Glauber Costa glommer@redhat.com --- src/optionroms.c | 11 ++++++++--- src/pci.c | 6 ++++-- 2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/optionroms.c b/src/optionroms.c index 37a4e6c..2d0a258 100644 --- a/src/optionroms.c +++ b/src/optionroms.c @@ -462,13 +462,18 @@ vga_setup(void) // Option roms are already deployed on the system. init_optionrom((void*)BUILD_ROM_START, 0, 1); } else { + int bdf; // Clear option rom memory memset((void*)RomEnd, 0, _max_rom() - RomEnd);
// Find and deploy PCI VGA rom. - int bdf = VGAbdf = pci_find_vga(); - if (bdf >= 0) - init_pcirom(bdf, 1, NULL); + do { + bdf = pci_find_vga(); + if (!VGAbdf) + VGAbdf = bdf; + if (bdf >= 0) + init_pcirom(bdf, 1, NULL); + } while ((bdf >= 0))
// Find and deploy CBFS vga-style roms not associated with a device. run_file_roms("vgaroms/", 1, NULL); diff --git a/src/pci.c b/src/pci.c index 944a393..6f124cf 100644 --- a/src/pci.c +++ b/src/pci.c @@ -107,7 +107,9 @@ pci_next(int bdf, int *pmax) int pci_find_vga(void) { - int bdf = 0x0000, max = 0x0100; + static int bdf; + int max = 0x0100; + for (;;) { if (bdf >= max) { if (CONFIG_PCI_ROOT1 && bdf <= (CONFIG_PCI_ROOT1 << 8)) @@ -132,7 +134,7 @@ pci_find_vga(void) u16 cmd = pci_config_readw(bdf, PCI_COMMAND); if (cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY) // Found active vga card - return bdf; + return bdf++; }
// Check if device is a bridge.
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
Sebastian
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
But supporting multiple VGA cards is something we want anyway since I think Spice uses this to have multiple heads. Gerd?
Regards,
Anthony Liguori
Sebastian
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
Sebastian
On Wed, 2011-05-04 at 00:02 +0200, Sebastian Herbszt wrote:
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
It is, but does not need to be (I've also patched sgabios to include a PCIR). Since it is a device, it is nice to have it plugged it to a bus. If for nothing else, for discovering capabilities - A guest using sgabios this way is now aware that it has a double-head system.
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
Sebastian
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:02 +0200, Sebastian Herbszt wrote:
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
It is, but does not need to be (I've also patched sgabios to include a PCIR). Since it is a device, it is nice to have it plugged it to a bus. If for nothing else, for discovering capabilities - A guest using sgabios this way is now aware that it has a double-head system.
I don't think "it is a device", more likely a functionality. SGAbios doesn't add a new device/hardware to the system. Do you plan to add a new (emulated) PCI device and deploy SGAbios thru its BAR? Do you plan to add support for "Google Memory Console"?
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
If you call the init function of two vga roms, will the last one win and hook int 10h?
Sebastian
On Wed, 2011-05-04 at 00:31 +0200, Sebastian Herbszt wrote:
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:02 +0200, Sebastian Herbszt wrote:
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
It is, but does not need to be (I've also patched sgabios to include a PCIR). Since it is a device, it is nice to have it plugged it to a bus. If for nothing else, for discovering capabilities - A guest using sgabios this way is now aware that it has a double-head system.
I don't think "it is a device", more likely a functionality. SGAbios doesn't add a new device/hardware to the system.
This depends on how you model it. One can think that this functionality is achieved by hooking a device into the system. "Hooking a device" is how most functionality is achieved in real systems anyway.
Do you plan to add a new (emulated) PCI device and deploy SGAbios thru its BAR?
Yes
Do you plan to add support for "Google Memory Console"?
No.
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
If you call the init function of two vga roms, will the last one win and hook int 10h?
Yes.
And this is totally orthogonal to whether it is loaded as a pci device, or in vgaroms/ The statement is true for both methods.
In the specific case of sgabios, it chains the int10h calls to whatever was there before, which is, IMHO, a very sane thing.
Sebastian
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:31 +0200, Sebastian Herbszt wrote:
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:02 +0200, Sebastian Herbszt wrote:
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote: > It is theorectically possible for a system to have more than > one pci vga card. In particular, I am interested in the use of SGAbios > as a pci device, alongside of a normal vga bios in QEMU.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
It is, but does not need to be (I've also patched sgabios to include a PCIR). Since it is a device, it is nice to have it plugged it to a bus. If for nothing else, for discovering capabilities - A guest using sgabios this way is now aware that it has a double-head system.
I don't think "it is a device", more likely a functionality. SGAbios doesn't add a new device/hardware to the system.
This depends on how you model it. One can think that this functionality is achieved by hooking a device into the system. "Hooking a device" is how most functionality is achieved in real systems anyway.
Do you plan to add a new (emulated) PCI device and deploy SGAbios thru its BAR?
Yes
Do you plan to add support for "Google Memory Console"?
No.
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
If you call the init function of two vga roms, will the last one win and hook int 10h?
Yes.
This might not always be the desired case. How can i control which card wins?
And this is totally orthogonal to whether it is loaded as a pci device, or in vgaroms/ The statement is true for both methods.
Shouldn't VGAbdf be set to the last (the winning) card then?
In the specific case of sgabios, it chains the int10h calls to whatever was there before, which is, IMHO, a very sane thing.
Sebastian
On Wed, 2011-05-04 at 00:51 +0200, Sebastian Herbszt wrote:
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:31 +0200, Sebastian Herbszt wrote:
Glauber Costa wrote:
On Wed, 2011-05-04 at 00:02 +0200, Sebastian Herbszt wrote:
Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote: > Glauber Costa wrote: >> It is theorectically possible for a system to have more than >> one pci vga card. In particular, I am interested in the use of SGAbios >> as a pci device, alongside of a normal vga bios in QEMU. > > Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
Why is this ugly and which additional hackery does it need? SGAbios is a legacy ROM; the PNP header is disabled and there is no PCIR.
It is, but does not need to be (I've also patched sgabios to include a PCIR). Since it is a device, it is nice to have it plugged it to a bus. If for nothing else, for discovering capabilities - A guest using sgabios this way is now aware that it has a double-head system.
I don't think "it is a device", more likely a functionality. SGAbios doesn't add a new device/hardware to the system.
This depends on how you model it. One can think that this functionality is achieved by hooking a device into the system. "Hooking a device" is how most functionality is achieved in real systems anyway.
Do you plan to add a new (emulated) PCI device and deploy SGAbios thru its BAR?
Yes
Do you plan to add support for "Google Memory Console"?
No.
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
If you call the init function of two vga roms, will the last one win and hook int 10h?
Yes.
This might not always be the desired case. How can i control which card wins?
Bus enumeration order, only. But that's a good question. Maybe we should come up with a method other than bus enumeration for that. But at the tip of my tongue, none come to mind.
And this is totally orthogonal to whether it is loaded as a pci device, or in vgaroms/ The statement is true for both methods.
Shouldn't VGAbdf be set to the last (the winning) card then?
That's certainly better, you are right.
In the specific case of sgabios, it chains the int10h calls to whatever was there before, which is, IMHO, a very sane thing.
Sebastian
On 2011-05-04 01:02, Glauber Costa wrote:
Also, let us not focus only in the specifics: Having two pci vga cards is a real possibility, there's even a use case for that, as anthony mentioned.
If you call the init function of two vga roms, will the last one win and hook int 10h?
Yes.
This might not always be the desired case. How can i control which card wins?
Bus enumeration order, only. But that's a good question. Maybe we should come up with a method other than bus enumeration for that. But at the tip of my tongue, none come to mind.
Normal BIOSes include an option in their menu to select the primary adapter. For QEMU use, we likely want some fw_cfg channel for this so that the user can select the primary adapter during VM configuration. Would be a nice feature.
Jan
On 05/03/11 23:44, Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
You are talking about https://code.google.com/p/sgabios/? /me wonders what pci device you are talking about?
This looks to be most useful for a headless system, i.e. 'qemu -nographic -vga none -optionrom sgabios.bin', then get the bios output (seaboot menu, pxe rom output, ...) on the serial line.
Note that seabios has serial line support already, although for debug purposes. Might be easy to extend that without too much trouble to a full-blown serial console support, which would have the advantage that seabios could show stuff on both serial line and vga.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
I fail to see why this requires seabios hackery. And legacy rom is the only way when using a isa-serial line.
We could add a pci-serial emulation[1] and load sgabios using the pci rom bar of that device.
But supporting multiple VGA cards is something we want anyway since I think Spice uses this to have multiple heads. Gerd?
The secondary qxl devices are a bit different. They are not vga compatible. They register as generic display class device. They have no vga bios. You need qxl guest drivers to drive them.
cheers, Gerd
[1] something like this ...
xeni kraxel ~/mockify# lspci -vs3.3 00:03.3 Serial controller: Intel Corporation 82G33/G31/P35/P31 Express Serial KT Controller (rev 02) (prog-if 02 [16550]) Subsystem: Intel Corporation 82G33/G31/P35/P31 Express Serial KT Controller Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17 I/O ports at e000 [size=8] Memory at ffa79000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: serial
xeni kraxel ~/mockify# grep 03.3 /var/log/dmesg pci 0000:00:03.3: reg 10 io port: [0xe000-0xe007] pci 0000:00:03.3: reg 14 32bit mmio: [0xffa79000-0xffa79fff] serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 0000:00:03.3: ttyS2 at I/O 0xe000 (irq = 17) is a 16550A
... should be doable with a just bit of pci plumbing for the existing serial emulation code.
On Wed, 2011-05-04 at 10:04 +0200, Gerd Hoffmann wrote:
On 05/03/11 23:44, Anthony Liguori wrote:
On 05/03/2011 03:23 PM, Sebastian Herbszt wrote:
Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
You are talking about https://code.google.com/p/sgabios/?
Yes
/me wonders what pci device you are talking about?
A dummy one, to represent it as a device in QEMU. As I stated before, I do know it is not strictly necessary. But after discussions in qemu mailing list, there was belief this could be the best way to model it, so whenever you want the functionality, you plug it in.
This looks to be most useful for a headless system, i.e. 'qemu -nographic -vga none -optionrom sgabios.bin', then get the bios output (seaboot menu, pxe rom output, ...) on the serial line.
unfortunately this does not work, because -optionrom puts everything under genroms. We need this at vgaroms/. The alternative to this, would be to simply patch qemu to do that (which I did already).
Note that seabios has serial line support already, although for debug purposes. Might be easy to extend that without too much trouble to a full-blown serial console support, which would have the advantage that seabios could show stuff on both serial line and vga.
I don't fully dislike this idea. Honestly, I kind of like it. Most of the work would be to add keyboard support for it. Just showing stuff in the serial console even when not debugging is quite easy.
Can't SGAbios be loaded as an option rom without this change?
But then you're loading it as a legacy ROM which is fairly ugly and requires additional SeaBIOS hackery.
I fail to see why this requires seabios hackery. And legacy rom is the only way when using a isa-serial line.
it requires hackery somewhere. Be it qemu, seabios, etc. Question is where is the best place to achieve that.
We could add a pci-serial emulation[1] and load sgabios using the pci rom bar of that device.
It would be basically the same of using -optiorom. With the same drawback: There are things the bios do between loading vga option roms and the other roms. And if sgabios is not loaded with the first team, this intermediate steps are lost.
But supporting multiple VGA cards is something we want anyway since I think Spice uses this to have multiple heads. Gerd?
The secondary qxl devices are a bit different. They are not vga compatible. They register as generic display class device. They have no vga bios. You need qxl guest drivers to drive them.
As a curiosity, do you then need a normal vga device to see boot messages? How does it work before you load the drivers?
cheers, Gerd
[1] something like this ...
xeni kraxel ~/mockify# lspci -vs3.3 00:03.3 Serial controller: Intel Corporation 82G33/G31/P35/P31 Express Serial KT Controller (rev 02) (prog-if 02 [16550]) Subsystem: Intel Corporation 82G33/G31/P35/P31 Express Serial KT Controller Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17 I/O ports at e000 [size=8] Memory at ffa79000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: serial
xeni kraxel ~/mockify# grep 03.3 /var/log/dmesg pci 0000:00:03.3: reg 10 io port: [0xe000-0xe007] pci 0000:00:03.3: reg 14 32bit mmio: [0xffa79000-0xffa79fff] serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17 0000:00:03.3: ttyS2 at I/O 0xe000 (irq = 17) is a 16550A
... should be doable with a just bit of pci plumbing for the existing serial emulation code.
Hi,
But supporting multiple VGA cards is something we want anyway since I think Spice uses this to have multiple heads. Gerd?
The secondary qxl devices are a bit different. They are not vga compatible. They register as generic display class device. They have no vga bios. You need qxl guest drivers to drive them.
As a curiosity, do you then need a normal vga device to see boot messages? How does it work before you load the drivers?
There are "qxl-vga" and "qxl" devices. The first variant is vga compatible (i.e. has bios, has vga mode, grabs isa vga ports, shows boot screen, ...), the other isn't. Once switched into native qxl mode there is no difference between those two devices.
cheers, Gerd
On Wed, May 04, 2011 at 10:04:18AM +0200, Gerd Hoffmann wrote:
You are talking about https://code.google.com/p/sgabios/?
Yes.
[...]
Note that seabios has serial line support already, although for debug purposes. Might be easy to extend that without too much trouble to a full-blown serial console support, which would have the advantage that seabios could show stuff on both serial line and vga.
This was raised on the coreboot side before. I'm okay if someone wants to implement an int10 and serial->keyboard wrapper in SeaBIOS.
To date, sgabios has worked fine, so there hasn't been a reason to do the extra work.
-Kevin
On Tue, May 03, 2011 at 01:49:57PM -0300, Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
This patch makes seabios continue searching the pci range looking for vga cards, even if it finds one. The first card to be found is assigned to VGAbdf, being the main one. The others, just have their initializatiom roms called and are listed in the pci bus.
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
The pci_find_vga() function attempts to find the VGA device with the legacy VGA ranges setup in PCI. It should only return one device regardless of the number of times it is called.
If you're looking to run an option ROM, the easiest way is to pass it through fw_cfg with a name prefix of "vgaroms/". SeaBIOS will then execute the ROM in addition to any found vga roms. One can put any number of roms in the "vgaroms/" directory.
Also sgabios doesn't need its own device - it works fine when run after the normal VGA bios is run. It forwards the output through serial, and then calls the regular VGA bios' int 10 handler. (It's used on coreboot - see http://www.coreboot.org/SeaBIOS#Adding_sgabios_support .)
-Kevin
On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote:
On Tue, May 03, 2011 at 01:49:57PM -0300, Glauber Costa wrote:
It is theorectically possible for a system to have more than one pci vga card. In particular, I am interested in the use of SGAbios as a pci device, alongside of a normal vga bios in QEMU.
This patch makes seabios continue searching the pci range looking for vga cards, even if it finds one. The first card to be found is assigned to VGAbdf, being the main one. The others, just have their initializatiom roms called and are listed in the pci bus.
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless.
The pci_find_vga() function attempts to find the VGA device with the legacy VGA ranges setup in PCI. It should only return one device regardless of the number of times it is called.
If you're looking to run an option ROM, the easiest way is to pass it through fw_cfg with a name prefix of "vgaroms/". SeaBIOS will then execute the ROM in addition to any found vga roms. One can put any number of roms in the "vgaroms/" directory.
I know all that, and I agree about easiest. It took me a couple of minutes to have it integrated into qemu that way. We, however, decided that it made more sense to us to have it exposed as a pci device. So easiness is not at stake here.
On Tue, May 03, 2011 at 09:41:48PM -0300, Glauber Costa wrote:
On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote:
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless.
I don't understand your question. For regular PCI devices every option rom should be run, regardles of how many devices are in the system. VGA option roms are special though - my understanding is exactly one VGA device should have its option rom executed.
-Kevin
On Tue, 2011-05-03 at 20:51 -0400, Kevin O'Connor wrote:
On Tue, May 03, 2011 at 09:41:48PM -0300, Glauber Costa wrote:
On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote:
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless.
I don't understand your question. For regular PCI devices every option rom should be run, regardles of how many devices are in the system. VGA option roms are special though - my understanding is exactly one VGA device should have its option rom executed.
let me rephrase then: what if you have n vga option roms under fw_cfg's vgaroms/ ? Would you execute only one of them?
On 05/04/2011 11:22 AM, Glauber Costa wrote:
On Tue, 2011-05-03 at 20:51 -0400, Kevin O'Connor wrote:
On Tue, May 03, 2011 at 09:41:48PM -0300, Glauber Costa wrote:
On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote:
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless.
I don't understand your question. For regular PCI devices every option rom should be run, regardles of how many devices are in the system. VGA option roms are special though - my understanding is exactly one VGA device should have its option rom executed.
let me rephrase then: what if you have n vga option roms under fw_cfg's vgaroms/ ? Would you execute only one of them?
I'm a bit confused. With sgabios, how is it normally loaded on bare metal? I thought it's often just flashed in a dummy PCI device, make part of the BIOS image with a bios editor, or even loaded as part of a NICs firmware.
Is it critical that this is loaded as a VGA rom verses a normal option ROM?
The only difference with VGA roms are that they are loaded slightly earlier in the process. You shouldn't lose a lot loading them with normal PCI option roms.
Regards,
Anthony Liguori
On Wed, 2011-05-04 at 11:51 -0500, Anthony Liguori wrote:
On 05/04/2011 11:22 AM, Glauber Costa wrote:
On Tue, 2011-05-03 at 20:51 -0400, Kevin O'Connor wrote:
On Tue, May 03, 2011 at 09:41:48PM -0300, Glauber Costa wrote:
On Tue, 2011-05-03 at 19:58 -0400, Kevin O'Connor wrote:
My understanding is that in a machine with multiple VGA devices only one vga device is setup to forward the legacy VGA IO ranges over PCI, and only that device should have its option ROM executed.
My understanding is that running the vga option roms for all vga devices would be incorrect and could cause a real machine to not boot properly.
how's that different in pci vs vgaroms/ ? "Could cause a real machine to not boot" is true regardless.
I don't understand your question. For regular PCI devices every option rom should be run, regardles of how many devices are in the system. VGA option roms are special though - my understanding is exactly one VGA device should have its option rom executed.
let me rephrase then: what if you have n vga option roms under fw_cfg's vgaroms/ ? Would you execute only one of them?
I'm a bit confused. With sgabios, how is it normally loaded on bare metal? I thought it's often just flashed in a dummy PCI device, make part of the BIOS image with a bios editor, or even loaded as part of a NICs firmware.
Is it critical that this is loaded as a VGA rom verses a normal option ROM?
In all my testing, yes.
The only difference with VGA roms are that they are loaded slightly earlier in the process. You shouldn't lose a lot loading them with normal PCI option roms.
The way it is today, it loses gpxe shell (probably dependent on execution order), and the boot menu.
If there is anything we care about interaction at boot time, it is those two.
On Wed, May 04, 2011 at 11:51:02AM -0500, Anthony Liguori wrote:
I'm a bit confused. With sgabios, how is it normally loaded on bare metal? I thought it's often just flashed in a dummy PCI device, make part of the BIOS image with a bios editor, or even loaded as part of a NICs firmware.
Yes.
Is it critical that this is loaded as a VGA rom verses a normal option ROM?
It runs as a regular option rom, but runs later in the boot.
The only difference with VGA roms are that they are loaded slightly earlier in the process.
In regard to sgabios - yes. (In general, vga roms are special in a few different ways.)
You shouldn't lose a lot loading them with normal PCI option roms.
You lose the boot menu. If sgabios runs after other roms, then you lose those rom's boot menus.
Not having access to the very beginning of the boot really limited sgabios' capabilities, so the "vgaroms/" trick was added to SeaBIOS. (In particular, one couldn't change the boot order on a real machine.) It's ~3 lines of code though.
-Kevin
On Wed, May 04, 2011 at 11:51:02AM -0500, Anthony Liguori wrote:
I'm a bit confused. With sgabios, how is it normally loaded on bare metal? I thought it's often just flashed in a dummy PCI device, make part of the BIOS image with a bios editor, or even loaded as part of a NICs firmware.
Yes.
Is it critical that this is loaded as a VGA rom verses a normal
option ROM?
It runs as a regular option rom, but runs later in the boot.
The only difference with VGA roms are that they are loaded slightly earlier in the process.
In regard to sgabios - yes. (In general, vga roms are special in a few different ways.)
You shouldn't lose a lot loading them with normal PCI option roms.
You lose the boot menu. If sgabios runs after other roms, then you lose those rom's boot menus.
Not having access to the very beginning of the boot really limited sgabios' capabilities, so the "vgaroms/" trick was added to SeaBIOS. (In particular, one couldn't change the boot order on a real machine.) It's ~3 lines of code though.
I'm a bit confused here. If we run sgabios with the other non-VGA option ROMS do we lose the boot menu? I would image that the boot menu would come after all option ROMs have been run? Does sgabios work with legacy BIOS's (I assume as a non-VGA ROM)?
I always assumed that the boot sequence was this: - do some HW initialisation - load first VGA option ROM - do some more HW initialisation - load all non-VGA option ROMS - show boot menu
I've played with adding debug via serial to a real VGA option ROM. This has fun problems if you are not using coreboot. On a real/legacy system the VGA option ROM is run very early, so that you get some output and can see what fails. It actually seems to get run before the superIO has been fully initialised, so you can't easily get serial output. (you also can't rely on "standard" hardware, like the timer)
My solution was to move to coreboot.
MM
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
On Wed, May 04, 2011 at 01:22:03PM -0300, Glauber Costa wrote:
let me rephrase then: what if you have n vga option roms under fw_cfg's vgaroms/ ?
Then both would be run.
If one were to put two real VGA ROMs in "vgaroms/", then both roms would be run, both would try to map hardware registers to 0xa0000-0xc0000, and things would break.
However, the sgabios isn't a "real" vga rom - it doesn't try to map 0xa0000. Instead, sgabios is just a blob of code that we'd like to run early so that it can hook int10.
The "vgaroms/" capability was added specifically to allow sgabios to run early in the boot.
http://www.coreboot.org/pipermail/coreboot/2009-May/048678.html
-Kevin
-
Anthony Liguori -
Gerd Hoffmann -
Glauber Costa -
Jan Kiszka -
Kevin O'Connor -
Mark Marshall -
Sebastian Herbszt