[PATCH 1/2] Add config option to move PORT_ACPI_PM_BASE out of the way
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- src/Kconfig | 7 +++++++ src/fw/paravirt.h | 9 +++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index cce3ad8..df3512d 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -309,6 +309,13 @@ menu "Hardware support" default y help Initialize the Memory Type Range Registers (on emulators). + config PMBASE_LOW + depends on QEMU + bool "Map ACPI PM below 0x1000" + default n + help + Map ACPI PM bar below 0x1000. This makes room in the io address + space for PCI bridges, but requires qemu 1.4+ to work correctly. config PMTIMER bool "Use ACPI timer" default y diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h index 69d7248..64fe4c6 100644 --- a/src/fw/paravirt.h +++ b/src/fw/paravirt.h @@ -29,8 +29,13 @@ static inline int runningOnKVM(void) { #define PORT_SMI_STATUS 0x00b3 #define PORT_QEMU_CFG_CTL 0x0510 #define PORT_QEMU_CFG_DATA 0x0511 -#define PORT_ACPI_PM_BASE 0xb000 -#define PORT_SMB_BASE 0xb100 +#ifdef CONFIG_PMBASE_LOW +# define PORT_ACPI_PM_BASE 0x0600 +# define PORT_SMB_BASE 0x0700 +#else +# define PORT_ACPI_PM_BASE 0xb000 +# define PORT_SMB_BASE 0xb100 +#endif #define PORT_BIOS_APM 0x8900 void qemu_preinit(void); -- 1.8.3.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- src/fw/pciinit.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 64f1d41..5ac08f4 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -43,6 +43,7 @@ u64 pcimem_start = BUILD_PCIMEM_START; u64 pcimem_end = BUILD_PCIMEM_END; u64 pcimem64_start = BUILD_PCIMEM64_START; u64 pcimem64_end = BUILD_PCIMEM64_END; +u64 pci_io_low_end = 0xa000; struct pci_region_entry { struct pci_device *dev; @@ -411,6 +412,12 @@ static void mch_mem_addr_setup(struct pci_device *dev, void *arg) pcimem_start = addr + size; pci_slot_get_irq = mch_pci_slot_get_irq; + + /* setup io address space */ + if (PORT_ACPI_PM_BASE < 0x1000) + pci_io_low_end = 0x10000; + else + pci_io_low_end = PORT_ACPI_PM_BASE; } static const struct pci_device_id pci_platform_tbl[] = { @@ -723,16 +730,11 @@ static int pci_bios_init_root_regions_io(struct pci_bus *bus) if (sum < 0x4000) { /* traditional region is big enougth, use it */ r_io->base = 0xc000; - } else if (sum < 0x9000) { + } else if (sum < pci_io_low_end - 0x1000) { /* use the larger region at 0x1000 */ r_io->base = 0x1000; } else { - /* - * Not enougth io address space -> error out. - * - * TODO: on q35 we can move PORT_ACPI_PM_BASE out of - * the way, then use the whole 1000 -> ffff region. - */ + /* Not enougth io address space -> error out. */ return -1; } dprintf(1, "PCI: IO: %4llx - %4llx\n", r_io->base, r_io->base + sum - 1); -- 1.8.3.1
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?) -Kevin
On Mi, 2014-02-05 at 20:04 -0500, Kevin O'Connor wrote:
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?)
qemu will look at the chipset registers programmed by the firmware and fill acpi accordingly. Which reminds me that this only works with qemu 1.8+ where qemu actually generates the acpi tables, so I should update the help text accordingly (raise minimum qemu version from 1.4 to 1.8). cheers, Gerd
On Thu, Feb 06, 2014 at 09:38:15AM +0100, Gerd Hoffmann wrote:
On Mi, 2014-02-05 at 20:04 -0500, Kevin O'Connor wrote:
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?)
qemu will look at the chipset registers programmed by the firmware and fill acpi accordingly. Which reminds me that this only works with qemu 1.8+ where qemu actually generates the acpi tables, so I should update the help text accordingly (raise minimum qemu version from 1.4 to 1.8).
Well, that's backwards. Can we change QEMU? -Kevin
On Do, 2014-02-06 at 10:21 -0500, Kevin O'Connor wrote:
On Thu, Feb 06, 2014 at 09:38:15AM +0100, Gerd Hoffmann wrote:
On Mi, 2014-02-05 at 20:04 -0500, Kevin O'Connor wrote:
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?)
qemu will look at the chipset registers programmed by the firmware and fill acpi accordingly. Which reminds me that this only works with qemu 1.8+ where qemu actually generates the acpi tables, so I should update the help text accordingly (raise minimum qemu version from 1.4 to 1.8).
Well, that's backwards.
Sort of, but nevertheless it makes perfect sense IMO. It fits naturally with the firmware initialization order: First setup hardware, then handle bios tables. So the firmware can program the hardware as it pleases, and when it loads the acpi tables from qemu later on they will have the correct addresses filled in. We also don't need any paravirtual interfaces to communicate the addresses between qemu and firmware: Firmware just sets the registers of the emulated hardware. Doing it the other way around is tricky for initialization order reasons, especially for coreboot. pmbase and mmconf xbar (those are looked up by the qemu acpi table generator) locations are (a) compile time constants and (b) programmed very early at boot time. cheers, Gerd
On Thu, Feb 06, 2014 at 04:40:28PM +0100, Gerd Hoffmann wrote:
On Do, 2014-02-06 at 10:21 -0500, Kevin O'Connor wrote:
On Thu, Feb 06, 2014 at 09:38:15AM +0100, Gerd Hoffmann wrote:
On Mi, 2014-02-05 at 20:04 -0500, Kevin O'Connor wrote:
On Mon, Feb 03, 2014 at 10:04:37AM +0100, Gerd Hoffmann wrote:
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Can't we detect this at runtime by reading the ACPI tables from QEMU? (Indeed, if it is a SeaBIOS config setting, how will QEMU know what to put in the ACPI tables?)
qemu will look at the chipset registers programmed by the firmware and fill acpi accordingly. Which reminds me that this only works with qemu 1.8+ where qemu actually generates the acpi tables, so I should update the help text accordingly (raise minimum qemu version from 1.4 to 1.8).
Well, that's backwards.
Sort of, but nevertheless it makes perfect sense IMO. It fits naturally with the firmware initialization order: First setup hardware, then handle bios tables. So the firmware can program the hardware as it pleases, and when it loads the acpi tables from qemu later on they will have the correct addresses filled in. We also don't need any paravirtual interfaces to communicate the addresses between qemu and firmware: Firmware just sets the registers of the emulated hardware.
Doing it the other way around is tricky for initialization order reasons, especially for coreboot. pmbase and mmconf xbar (those are looked up by the qemu acpi table generator) locations are (a) compile time constants and (b) programmed very early at boot time.
Ahh - I vaguely recall discussing this before. However, I don't think it makes sense for SeaBIOS to have a compile time definition on where to place the mappings. Can't it be pulled from fwcfg? -Kevin
Hi,
Doing it the other way around is tricky for initialization order reasons, especially for coreboot. pmbase and mmconf xbar (those are looked up by the qemu acpi table generator) locations are (a) compile time constants and (b) programmed very early at boot time.
Ahh - I vaguely recall discussing this before.
However, I don't think it makes sense for SeaBIOS to have a compile time definition on where to place the mappings. Can't it be pulled from fwcfg?
Current smm code requires pmbase being a compile time constant. IIRC there was a experimental patch changing that last time we discussed this, but it wasn't merged. Once we have that we can make pmbase depend on fw_cfg, either indirectly (if qemu provides acpi tables it is new enough to handle pmbase being mapped at a non-traditional location), or by qemu suggesting a location in a (to be created) fw_cfg file. cheers, Gerd
participants (2)
-
Gerd Hoffmann -
Kevin O'Connor