Re: [SeaBIOS] [PATCH] pci vga: Support VGA behind bridges
On Thu, Feb 28, 2013 at 10:52:49AM -0700, Alex Williamson wrote: > We currently expect to find VGA devices on the root bus but we will > also support them below bridges iff the VGA routing across the bridges > is pre-configured. This patch maintains that behavior, but also > enables SeaBIOS to enable VGA routing to the first VGA class device it > finds when there is no preconfigured device. This allows us to > support VGA devices behind root ports and bridges without special > setup from QEMU. [...] > --- a/src/optionroms.c > +++ b/src/optionroms.c > @@ -439,13 +439,47 @@ vgarom_setup(void) I don't think that optionroms.c is the right place for this logic. On coreboot, Xen, and CSM, SeaBIOS shouldn't be touching the PCI config. It's only QEMU that would need this logic, so something like pciinit.c is where this logic should go. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] RFC: Primary VGA
On Thu, 28 Feb 2013 08:26:54 -0700
Alex Williamson 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.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] pci vga: Support VGA behind bridges
We currently expect to find VGA devices on the root bus but we will
also support them below bridges iff the VGA routing across the bridges
is pre-configured. This patch maintains that behavior, but also
enables SeaBIOS to enable VGA routing to the first VGA class device it
finds when there is no preconfigured device. This allows us to
support VGA devices behind root ports and bridges without special
setup from QEMU.
Signed-off-by: Alex Williamson
---
src/optionroms.c | 46 --
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index caa2151..1c2a714 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -439,13 +439,47 @@ vgarom_setup(void)
memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START);
// Find and deploy PCI VGA rom.
-struct pci_device *pci;
+struct pci_device *pci, *pci_vga = NULL;
+// Search for devices already enabled
foreachpci(pci) {
-if (!is_pci_vga(pci))
-continue;
-vgahook_setup(pci);
-init_pcirom(pci, 1, NULL);
-break;
+if (is_pci_vga(pci)) {
+pci_vga = pci;
+break;
+}
+}
+
+// Find and enable the first VGA device
+if (!pci_vga && (pci = pci_find_class(PCI_CLASS_DISPLAY_VGA)) != NULL)
{
+dprintf(4, "Enabling device %02x:%02x.%x for primary VGA\n",
+pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+pci_bdf_to_fn(pci->bdf));
+
+u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+
+pci_vga = pci;
+
+while (pci->parent) {
+pci = pci->parent;
+
+dprintf(4, "Setting VGA enable for bridge %02x:%02x.%x\n",
+pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+pci_bdf_to_fn(pci->bdf));
+
+u8 ctrl = pci_config_readb(pci->bdf, PCI_BRIDGE_CONTROL);
+ctrl |= PCI_BRIDGE_CTL_VGA;
+pci_config_writeb(pci->bdf, PCI_BRIDGE_CONTROL, ctrl);
+
+u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+}
+}
+
+if (pci_vga) {
+vgahook_setup(pci_vga);
+init_pcirom(pci_vga, 1, NULL);
}
// Find and deploy CBFS vga-style roms not associated with a device.
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] RFC: Primary VGA
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH] Distinguish between reset types
On 02/20/2013 07:37 AM, David Woodhouse wrote: > On Wed, 2013-02-20 at 16:34 +0100, Paolo Bonzini wrote: >> Il 20/02/2013 16:18, Laszlo Ersek ha scritto: > I'm beginning to wish I'd just ignored the fact that > we need a properly working "soft" reset to get back from 286 protected > mode to real mode, and wired up the damn PAM reset unconditionally. I'm > not convinced that the protected->real mode transition will work for > anyone anyway. >>> I believe currently we must be somewhere "between" soft reset & hard >>> reset. I estimate getting closer to a well-emulated hard reset is more >>> important than getting closer to a soft one. If you were to extend the >>> i440FX reset handler so that it unconditionally resets the PAMs, I'd >>> give my Rb. (Take it for what it's worth :)) >> >> It would actually make sense. The right way to do soft reset has >> nothing to do with qemu_system_reset_request(). > > I've posted that version of the patch, with a suitable comment. > Right... the "soft reset" described above is really INIT, which isn't even a reset in modern CPUs (it couldn't be, it has to preserve caches) but more of a special interrupt. It is also used during multiprocessor init. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/28/13 10:37, David Woodhouse wrote: > On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote: >> >>> 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems >>> wildly schizophrenic without bringing any significant benefits, >>> compared to factoring all of that out into a codebase which *already >>> does many of the needed things*. >> >> It's a tradeoff. On one hand letting coreboot handle hardware >> initialialization would reduce the amout of code in seabios we have to >> maintain. On the other hand adding coreboot as middle man between qemu >> and seabios would add some complexity to the whole mix. > > But if we do it *without* coreboot, then we get to reimplement the whole > "seabios-qemu-seabios ping-pong", as Laszlo describes it, in Tianocore > as *well* as SeaBIOS. A good part of that "ping pong" is for acpi table generation. That we don't want duplicate *that* in both tianocore and seabios is pretty clear. So the question is whenever we want move acpi table generation to coreboot or to qemu? The advantage of moving it to coreboot is that we already have some table generation infrastructure there. The advantage of moving it to qemu is that we can easily keep acpi tables in sync with the virtual hardware. We need less communication between qemu + firmware. We gain flexibility: All firmware (seabios / tianocore / coreboot) can pick up & use the tables. That way we should get a smooth migration path from pure seabios to coreboot+seabios (or coreboot+tianocore+seabios), can switch firmware images for regression testing etc. > Using coreboot everywhere sounds good to me. Especially because on the > Tianocore side we can push for Patrick's CorebootPkg to be the *primary* > platform; we could even consider deprecating the qemu-specific OvmfPkg > completely. And *that* in turn ensures that what everyone's working on > is something that ought to be suitable for real hardware, rather than > just qemu. Makes sense, but is quite some way to go. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Hi, sorry for the delay. On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote: > On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis < > vasilis.liaskovi...@profitbricks.com> wrote: > > > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is > > supported (both i440fx and q35). There are still several issues, but it's > > been a while since v3 and I wanted to get some more feedback on the current > > state of the patchseries. > > > > > We are working in memory hotplug functionality on pSeries machine. I'm > wondering whether and how we can better integrate things. Do you think the > DIMM abstraction is generic enough to be used in other machine types? I think the DimmDevice is generic enough but I am open to other suggestions. A related issue is that the patchseries uses a DimmBus to hot-add and hot-remove DimmDevice. Another approach that has been suggested is to use links<> between DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc machines respectively). This would be more similar to the CPUState/qom patches - see Andreas Färber's earlier reply to this thread. I think we should get some consensus from the community/maintainers before we continue to integrate. I haven't updated the series for a while, but I can rework if there is a more clear direction for the community. Another open issue is reference counting of memoryregions in qemu memory model. In order to make memory hot-remove operations safe, we need to remove a memoryregion after all users (e.g. both guest and block layer) have stopped using it, see discussion at http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There was a relevant ibm patchset https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html but it was not merged. > > > > Overview: > > > > Dimm device layout is modeled with a normal qemu device: > > > > "-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0" > > > > > How does this will handle the no-hotplugable memory for example the memory > passed in '-m' parameter? The non-hotpluggable initial memory (-m) is currently not modelled at all as a DimmDevice. We may want to model it though. thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On Mon, 2013-02-25 at 15:46 +0100, Gerd Hoffmann wrote: > > > 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems > > wildly schizophrenic without bringing any significant benefits, > > compared to factoring all of that out into a codebase which *already > > does many of the needed things*. > > It's a tradeoff. On one hand letting coreboot handle hardware > initialialization would reduce the amout of code in seabios we have to > maintain. On the other hand adding coreboot as middle man between qemu > and seabios would add some complexity to the whole mix. But if we do it *without* coreboot, then we get to reimplement the whole "seabios-qemu-seabios ping-pong", as Laszlo describes it, in Tianocore as *well* as SeaBIOS. I'm not sure we really want to duplicate that code, which looks like it will have tricky interactions between host and guest. When viewed that way, it's not clear that doing it in coreboot is really adding complexity; in that respect it *simplifies* things a bit. Using coreboot everywhere sounds good to me. Especially because on the Tianocore side we can push for Patrick's CorebootPkg to be the *primary* platform; we could even consider deprecating the qemu-specific OvmfPkg completely. And *that* in turn ensures that what everyone's working on is something that ought to be suitable for real hardware, rather than just qemu. It would also help some people on the UEFI side to get over their bizarre misconception that coreboot is antithetical to UEFI :) I'd be quite happy to get to the point where the default firmware for Qemu is Coreboot + Tianocore + SeaBIOS (as CSM). -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
On 02/28/13 06:23, Peter Stuge wrote: > Gerd Hoffmann wrote: >> Option one is to let qemu provide them, then both ovmf and seabios can >> grab them via fw_cfg. >> >> Option two is to use coreboot underneath > > I don't think one should exclude the other, I think it would make > great sense to combine them. So have coreboot on QEMU read some > hardware description from QEMU and use that either as input to a > table generator, or even have the read data be the tables themselves. Yes, sure, if we let qemu generate the tables coreboot can just grab+use them too. But the coreboot table generator code wouldn't be used then ... >> From the quick look it seems they do *not* generate the dsdt >> dynamically, only the other tables (simliar to seabios). So >> switching to coreboot probably doesn't help to remove the dsdt >> patching code we have in seabios. > > Is there something inherent to the AML generator code in coreboot > which makes it suck for the purpose of also generating a DSDT? I think it is alot of work to get that going. Typically the dsdt is static while any dynamic stuff is placed in a (generated) ssdt and is just referenced from the dsdt. coreboot is not different here, consequently it has ready-to-go code to generate the stuff typically found in ssdt (and other) tables. But support for generating dsdt constructs simply isn't there (or very limited, some ressource template bits seem to be there because those are used in ssdts too). cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
