summaryrefslogtreecommitdiff
path: root/arch/x86/cpu/qemu/qemu.c
diff options
context:
space:
mode:
authorTom Rini <trini@konsulko.com>2025-04-03 11:43:38 -0600
committerTom Rini <trini@konsulko.com>2025-04-03 11:43:38 -0600
commit1f2a3d066c99f57675162ce09586e9de30407f1b (patch)
tree40bfceab01cc1c6a035eb66792638149400db1ef /arch/x86/cpu/qemu/qemu.c
parent39ff722b3ee0bd569388a3b89c59899511ac1a24 (diff)
parenta3d255d996b346c527962926ff80343e02ae8f00 (diff)
Merge patch series "x86: Improve operation under QEMU"
Simon Glass <sjg@chromium.org> says: U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it is not perfect. With both builds, executing the VESA ROM causes an intermittent hang, at least on some AMD CPUs. With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) is done in a way that works on real hardware but not with QEMU. This means that performance is 4-5x slower than it could be, at least on my CPU. We can work around the first problem by using Bochs, which is anyway a better choice than VESA for QEMU. The second can be addressed by using the same descriptor across the jump to long mode. With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 In v3 some e820 patches are included to make booting reliable and avoid ACPI tables being dropped. Also, several MTTR problems are addressed, to support memory sizes above 4GB reliably. Link: https://lore.kernel.org/all/20250315142643.2600605-1-sjg@chromium.org/
Diffstat (limited to 'arch/x86/cpu/qemu/qemu.c')
-rw-r--r--arch/x86/cpu/qemu/qemu.c20
1 files changed, 14 insertions, 6 deletions
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 563f63e2bc8..e846ccd44aa 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -15,14 +15,21 @@
#include <asm/arch/qemu.h>
#include <asm/u-boot-x86.h>
-static bool i440fx;
-
#if CONFIG_IS_ENABLED(QFW_PIO)
U_BOOT_DRVINFO(x86_qfw_pio) = {
.name = "qfw_pio",
};
#endif
+static bool is_i440fx(void)
+{
+ u16 device;
+
+ pci_read_config16(PCI_BDF(0, 0, 0), PCI_DEVICE_ID, &device);
+
+ return device == PCI_DEVICE_ID_INTEL_82441;
+}
+
static void enable_pm_piix(void)
{
u8 en;
@@ -50,16 +57,17 @@ static void enable_pm_ich9(void)
void qemu_chipset_init(void)
{
- u16 device, xbcs;
+ bool i440fx;
+ u16 xbcs;
int pam, i;
+ i440fx = is_i440fx();
+
/*
* i440FX and Q35 chipset have different PAM register offset, but with
* the same bitfield layout. Here we determine the offset based on its
* PCI device ID.
*/
- pci_read_config16(PCI_BDF(0, 0, 0), PCI_DEVICE_ID, &device);
- i440fx = (device == PCI_DEVICE_ID_INTEL_82441);
pam = i440fx ? I440FX_PAM : Q35_PAM;
/*
@@ -123,7 +131,7 @@ int mp_determine_pci_dstirq(int bus, int dev, int func, int pirq)
{
u8 irq;
- if (i440fx) {
+ if (is_i440fx()) {
/*
* Not like most x86 platforms, the PIRQ[A-D] on PIIX3 are not
* connected to I/O APIC INTPIN#16-19. Instead they are routed