Thank you for this message! Some comments below: On 03/07/16 09:47, Gerd Hoffmann wrote: > Hi, > >> PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 > > Ok, I see you mimic seabios behavior here, resulting in a somewhat odd > memory layout (not your fault, of course). > > Short history lesson: > > Traditional i440fx memory layout (before we did gigabyte alignment) was > memory up to 0xe0000000, pci io space above that. Which caused problems > now and then, because it isn't that much address space for pci. > > So, when figuring how to do things on q35 I wanted more space. Decided > to go down to 0xc0000000, giving additional 512m address space for pci. > But we also have to place the xbar somewhere. The seabios code to do > pci bar placement is somewhat simple and can deal with a single (32bit) > I/O window only. Decided to place the xbar @ 0xb0000000, so seabios has > a single region above 0xc0000000 for the I/O bars. > > So, this is where the traditional q35 memory layout with memory up to > 0xafffffff comes from. These days it doesn't look that way any more > because we added gigabyte alignment meanwhile, so it's this now: > > low memory 0x00000000 -> 0x7fffffff. > free space 0x80000000 -> 0xafffffff, > mmcfg xbar 0xb0000000 -> 0xbfffffff, > free space 0xc0000000 -> ioapic-base > > i.e. the xbar splits the free space in a somewhat unclever way. > > The good news is that xbar location is not fixed. qemu is supposed to > check now the firmware programmed the q35 host bridge and fill the acpi > tables accordingly, so you should be able to move the xbar to another > location. > > I think there are two reasonable choices: Either 0x80000000 or > 0xe0000000. > > Using 0x80000000 maintains a single I/O window. (above 0x90000000). > Gives up backward compatibility to really old (pre gigabyte alignment) > q35 machines types. But we are about to drop support for them in > upstream qemu anyway, so I'll probably switch seabios to do that. > > Using 0xe0000000 still splits the I/O address space into two pieces, but > I don't think the edk2 resource management code has problems dealing > with that.
The current abstraction we're using with the new core PCI host bridge driver allows for a single contiguous range as MMIO32 aperture. (And, in OVMF's case, that range is shared between the root bridges, if there are several of them -- but I digress.) The point is, we should indeed come up with the best split. > It places the xbar at the highest possible address, so we > get a big I/O window below the xbar (and a small one above). The main > advantage over using 0xb0000000 is that you can better fit big bars > then, for example you can map even a 1G bar (at 0x8000000). Okay, my vote is 0x8000_0000 (2GB) then. I will modify the patch as follows: simultaneously with programming the exbar at 2GB, I will lower the start of the 32-bit PCI aperture from the current 3GB (0xC000_0000) to (2GB+256MB == 0x9000_0000). Is that alright? Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
