When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this. Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary. The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient. If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps "primary_vga". A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id. We'll also need some reasonable way to pick a default if unspecified. Does anyone have any thoughts on managing this? Thanks, Alex
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote:
When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this.
Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary.
The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient.
SeaBIOS uses the VGA PCI routing information to determine which option rom to run. However, it doesn't actually initialize the VGA PCI routing in it's PCI initialization code (pciinit.c). This isn't an issue for the default QEMU setup because QEMU does not place the VGA card behind a bus. However, should QEMU support multiple VGA cards and/or VGA cards behind a bus, then the PCI init code would likely need to handle VGA setup. (I suppose QEMU could setup the bus forwarding of the legacy VGA ranges, but it would seem ugly to have SeaBIOS do most of the PCI init while QEMU did this small part.) -Kevin
On Wed, 2013-02-27 at 20:11 -0500, Kevin O'Connor wrote:
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote:
When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this.
Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary.
The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient.
SeaBIOS uses the VGA PCI routing information to determine which option rom to run. However, it doesn't actually initialize the VGA PCI routing in it's PCI initialization code (pciinit.c). This isn't an issue for the default QEMU setup because QEMU does not place the VGA card behind a bus. However, should QEMU support multiple VGA cards and/or VGA cards behind a bus, then the PCI init code would likely need to handle VGA setup. (I suppose QEMU could setup the bus forwarding of the legacy VGA ranges, but it would seem ugly to have SeaBIOS do most of the PCI init while QEMU did this small part.)
Supporting VGA behind root ports is inevitable, modern topologies demand it and I've got rough working code to enable it for assigned devices. Once we have root ports, there's no reason bridges shouldn't also be supported and maybe we can even deprecate the QEMU -vga option in favor if a regular -device option. It does make some sense that SeaBIOS initializes PCI, so should be responsible for this programming. Should we just start with a bus ordered search for the first PCI VGA class device we find and enable routing for that device? If we do that, perhaps we can defer the question of whether QEMU can specify an alternate primary device. Thanks, Alex
Gerd Hoffmann wrote:
gets. It sounds like there will soon be need for a more generic PCI resource allocator, which is another thing that coreboot already has.
--verbose please.
Alex Williamson wrote:
It does make some sense that SeaBIOS initializes PCI, so should be responsible for this programming.
That. //Peter
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote:
When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this.
Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary.
The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient.
If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps "primary_vga". A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id.
Yes. And a command to change it when we support hotplug in the future?
We'll also need some reasonable way to pick a default if unspecified.
Does anyone have any thoughts on managing this? Thanks,
Alex
On Thu, 2013-02-28 at 08:50 +0200, Michael S. Tsirkin wrote:
On Wed, Feb 27, 2013 at 02:16:23PM -0700, Alex Williamson wrote:
When we start adding root ports and bridges to systems we need some concept of a primary VGA device.The differentiation of the primary device is that it's the default one that responds to the Legacy VGA address ranges. PCs often have a BIOS selection for this.
Seabios already seems to have some concept of this and looks for a VGA class device for which the parent devices all have VGA routing enabled. This seems to work today if QEMU initializes VGA routing for the path it considers the primary.
The first question is whether this bridge path pre-configuration is what we want to keep as the way QEMU communicates the primary VGA device to Seabios? Obviously we could switch to some kind of fwcfg interface, but I tend to think what we have is sufficient.
If it is sufficient, then I think we need to rebuild that path on system reset and we need some way to specify which device to use. One option would be some kind of per PCIDevice property, perhaps "primary_vga". A downside is that users can abuse it by trying to set it for more than one device. Maybe a better approach would be to add a machine property for it, -machine primary_vga=$id.
Yes. And a command to change it when we support hotplug in the future?
Looking at how this would happen on bare metal, there are ACPI methods _GPD (Get Post Device), _SPD (Set Post Device), and _VPD (Video Post Options). So I imagine that if we supported VGA hotplug we'd use those to let the guest specify the primary and continue to use an algorithm in SeaBIOS to post to the lowest B:D.F VGA device if unspecified. I don't know that we need some kind of QMP/QAPI runtime command to change the VGA post device externally on the next boot, real systems likely doesn't have such a hook. For now I'll just start with making SeaBIOS have a way to enable and post the first VGA device when it's behind bridges. Thanks, Alex
We'll also need some reasonable way to pick a default if unspecified.
Does anyone have any thoughts on managing this? Thanks,
Alex
On Thu, 28 Feb 2013 08:26:54 -0700 Alex Williamson <alex.williamson@redhat.com> wrote:
Looking at how this would happen on bare metal, In coreboot(which can use SeaBIOS as a payload) it currently works like that (in src/device/device.c ): /* If we prefer plugin VGA over chipset VGA, the chipset might want to know. */ if (!CONFIG_ONBOARD_VGA_IS_PRIMARY && (vga != vga_onboard) && vga_onboard && vga_onboard->ops && vga_onboard->ops->disable) { printk(BIOS_DEBUG, "Use plugin graphics over integrated.\n"); vga_onboard->ops->disable(vga_onboard); } which calls a function like that: static void rs780_internal_gfx_disable(device_t dev) { u32 l_dword; device_t nb_dev = dev_find_slot(0, 0);
/* Disable internal GFX and enable external GFX. */ l_dword = pci_read_config32(nb_dev, 0x8c); l_dword |= 1<<0; l_dword &= ~(1<<1); pci_write_config32(nb_dev, 0x8c, l_dword); dev->enabled = 0; } So only one card is enabled at the same time... Denis.
participants (5)
-
Alex Williamson -
Denis 'GNUtoo' Carikli -
Kevin O'Connor -
Michael S. Tsirkin -
Peter Stuge