* [PATCH v6 1/7] xen/igd: get PCH info from host sysfs
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 2/7] xen/igd: don't register rom bar twice Chuck Zmudzinski
` (6 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
The igd_combo_id_infos[] data is out of date with many
devices missing from igd_combo_id_infos[]. For newer
devices not in igd_combo_id_infos[], get the infos from
the host sysfs. If logging is configured, print log
messages displaying the PCH info used for the guest.
Introduce helper function xen_pt_get_host_pch_info() to
facilitate getting the necessary information from sysfs.
Treat failure to get the host PCH device id as an unrecoverable
error that causes guest creation to fail. If access to the host
PCH device revision id fails, print a warning message and use
a default value of 0x1 in that case.
Also, use errp in xen_igd_passthrough_isa_bridge_create()
to set errors from xen_pt_get_host_pch_info() and cleanup
on error path with xen_host_pci_device_put(&s->real_device)
and object_unparent(OBJECT(&d->rom)) for errors when creating
creating the IGD PCH bridge.
Add cleanup with object_unparent(OBJECT(&d->rom)) for errors
when setting up VGA BIOS for GFX passthrough.
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- No changes
Changes in v5:
- Shorten warn_report message to resolve checkpatch line length warning
Changes in v4:
- re-wrote xen_pt_get_host_pch_info() using functions from
xen-host-pci-device.h
- add more error handling to clean up better after if errors occur
- don't consider failure to get the PCH device revision id a fatal
error but instead print a warning message and use a default value
of 0x1
hw/xen/xen_pt.c | 10 +++++++++-
hw/xen/xen_pt_graphics.c | 39 +++++++++++++++++++++++++++++++++++++--
include/hw/xen/xen_igd.h | 3 ++-
3 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 0fe9c0a..c8f08b5 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -862,12 +862,20 @@ static void xen_pt_realize(PCIDevice *d, Error **errp)
if (*errp) {
error_append_hint(errp, "Setup VGA BIOS of passthrough"
" GFX failed");
+ object_unparent(OBJECT(&d->rom));
xen_host_pci_device_put(&s->real_device);
return;
}
/* Register ISA bridge for passthrough GFX. */
- xen_igd_passthrough_isa_bridge_create(s, &s->real_device);
+ xen_igd_passthrough_isa_bridge_create(s, &s->real_device, errp);
+ if (*errp) {
+ error_append_hint(errp, "Failed to create PCH bridge"
+ " for passthrough GFX");
+ object_unparent(OBJECT(&d->rom));
+ xen_host_pci_device_put(&s->real_device);
+ return;
+ }
}
/* Handle real device's MMIO/PIO BARs */
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index 7df9344..cf424bc 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -2,6 +2,7 @@
* graphics passthrough
*/
#include "qemu/osdep.h"
+#include "qemu/error-report.h"
#include "qapi/error.h"
#include "hw/xen/xen_pt.h"
#include "hw/xen/xen_igd.h"
@@ -376,8 +377,33 @@ static void pt_graphics_register_types(void)
}
type_init(pt_graphics_register_types)
+static void xen_pt_get_host_pch_info(uint16_t *pch_dev_id, uint8_t *pch_rev_id,
+ Error **errp)
+{
+ g_autofree XenHostPCIDevice *pch_dev = g_new(XenHostPCIDevice, 1);
+
+ xen_host_pci_device_get(pch_dev, 0, 0, 0x1f, 0, errp);
+ if (*errp) {
+ goto error;
+ }
+
+ *pch_dev_id = pch_dev->device_id;
+
+ if (xen_host_pci_get_byte(pch_dev, PCI_REVISION_ID, pch_rev_id)) {
+ *pch_rev_id = 0x1;
+ warn_report("IGD: failed to get host PCH revision, setting it to 0x1");
+ }
+
+ xen_host_pci_device_put(pch_dev);
+ return;
+
+error:
+ error_append_hint(errp, "failed to get host PCH device for Intel IGD");
+}
+
void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
- XenHostPCIDevice *dev)
+ XenHostPCIDevice *dev,
+ Error **errp)
{
PCIBus *bus = pci_get_bus(&s->dev);
struct PCIDevice *bridge_dev;
@@ -394,7 +420,16 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
}
}
+ /* Newer devices get PCH infos from host sysfs */
+ if ((pch_dev_id == 0xffff) || !pch_rev_id) {
+ xen_pt_get_host_pch_info(&pch_dev_id, &pch_rev_id, errp);
+ }
+
+ XEN_PT_LOG(&s->dev, "PCH device id: 0x%x\n", pch_dev_id);
+ XEN_PT_LOG(&s->dev, "PCH revision: 0x%x\n", pch_rev_id);
+
if (pch_dev_id == 0xffff) {
+ error_setg(errp, "failed to get PCH device id");
return;
}
@@ -406,7 +441,7 @@ void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
* Note that vendor id is always PCI_VENDOR_ID_INTEL.
*/
if (!bridge_dev) {
- fprintf(stderr, "set igd-passthrough-isa-bridge failed!\n");
+ error_setg(errp, "set igd-passthrough-isa-bridge failed!");
return;
}
pci_config_set_device_id(bridge_dev->config, pch_dev_id);
diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h
index 7ffca06..da51f09 100644
--- a/include/hw/xen/xen_igd.h
+++ b/include/hw/xen/xen_igd.h
@@ -22,7 +22,8 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s);
void xen_igd_reserve_slot(PCIBus *pci_bus);
void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val);
void xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
- XenHostPCIDevice *dev);
+ XenHostPCIDevice *dev,
+ Error **errp);
static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
{
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 2/7] xen/igd: don't register rom bar twice
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 1/7] xen/igd: get PCH info from host sysfs Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 3/7] xen/igd: fixup device id before registering rom Chuck Zmudzinski
` (5 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
This also fixes a failed assertion in pci [1] for Qemu
version 10 and higher when passing through an Intel
IGD with an option ROM to the guest.
[1] f6fc01c78666 ("hw/pci: Assert a bar is not registered multiple times")
Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- No changes to this patch
Changes in v5:
- No changes to this patch
Changes in v4:
- Use 12 digits for commit hashes
hw/xen/xen_pt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index c8f08b5..4d159a2 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -459,6 +459,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
{
int i = 0;
XenHostPCIDevice *d = &s->real_device;
+ const pcibus_t romsize = s->dev.io_regions[PCI_ROM_SLOT].size;
/* Register PIO/MMIO BARs */
for (i = 0; i < PCI_ROM_SLOT; i++) {
@@ -495,7 +496,7 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s, uint16_t *cmd)
}
/* Register expansion ROM address */
- if (d->rom.base_addr && d->rom.size) {
+ if (!romsize && d->rom.base_addr && d->rom.size) {
uint32_t bar_data = 0;
/* Re-set BAR reported by OS, otherwise ROM can't be read. */
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 3/7] xen/igd: fixup device id before registering rom
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 1/7] xen/igd: get PCH info from host sysfs Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 2/7] xen/igd: don't register rom bar twice Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 4/7] xen/igd: enable guest creation when ROM read fails Chuck Zmudzinski
` (4 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
With the current implementation, Seabios does not see the fixup of
the device id done here and consequently Seabios does not load the
VGA bios and the guest screen does not light up until the guest OS
graphics driver is loaded. So there is no VGA output from the passed
through Intel IGD from either Seabios or the guest bootloader with
the current implementation in cases when the device id needs fixing.
Fix this by waiting until after doing fixup of the device id before
registering the option ROM. With this patch, Seabios sees the fixup
done here and loads the VGA bios, and both Seabios and the guest
bootloader light up the guest screen in cases when fixup of the
device id is needed.
Also, remove unused header hw/core/loader.h.
Fixes: 881213f1b9c5 ("xen, gfx passthrough: retrieve VGA BIOS to work")
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- No changes to this patch
Changes in v5:
- No changes to this patch
Changes in v4:
- Add a Fixes tag
hw/xen/xen_pt_graphics.c | 3 +++
hw/xen/xen_pt_load_rom.c | 18 ++++++++++++------
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index cf424bc..c5ab23e 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -223,6 +223,9 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
}
}
+ pci_register_bar(&s->dev, PCI_ROM_SLOT, 0, &s->dev.rom);
+ s->dev.has_rom = true;
+
/* Currently we fixed this address as a primary for legacy BIOS. */
physical_memory_write(0xc0000, bios, bios_size);
}
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 319efca..407b630 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -4,14 +4,22 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
-#include "hw/core/loader.h"
#include "hw/pci/pci.h"
#include "xen_pt.h"
/*
- * Scan the assigned devices for the devices that have an option ROM, and then
- * load the corresponding ROM data to RAM. If an error occurs while loading an
- * option ROM, we just ignore that option ROM and continue with the next one.
+ * Normally xen_pt_register_regions will handle loading the option ROM,
+ * but in some cases, such as for the Intel IGD, the option ROM might
+ * need to be modified.
+ *
+ * For such cases, use this function to get a pointer to the option ROM
+ * from sysfs. Caller has the responsibility to edit the option ROM as
+ * needed, call pci_register_bar to register the modified option ROM,
+ * and set has_rom to true for the PCI device.
+ *
+ * This function must be called before xen_pt_register_regions is called
+ * because if xen_pt_register_regions is called first, it will register
+ * the option ROM and any attempt to register it again will fail.
*/
void *pci_assign_dev_load_option_rom(PCIDevice *dev,
int *size, unsigned int domain,
@@ -76,8 +84,6 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
goto close_rom;
}
- pci_register_bar(dev, PCI_ROM_SLOT, 0, &dev->rom);
- dev->has_rom = true;
*size = st.st_size;
close_rom:
/* Write "0" to disable ROM */
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 4/7] xen/igd: enable guest creation when ROM read fails
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
` (2 preceding siblings ...)
2026-09-11 7:24 ` [PATCH v6 3/7] xen/igd: fixup device id before registering rom Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 5/7] xen/igd: use igd header for IGD related definitions Chuck Zmudzinski
` (3 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
For newer IGD devices, the host option ROM is not readable from sysfs
and this results in a call to error_fail() that causes Qemu to
exit(1) so guest creation fails with the current implementation for
many newer IGD devices. But this read failure need not be a fatal
error causing guest creation to fail because the guest does not need
the option ROM to successfully boot and run. The guest only needs the
option ROM for getting graphics output from the guest during early
boot before the guest OS loads the Intel IGD graphics drivers.
To fix this, allow guest creation to continue by avoiding setting errp
if the attempt to read the host ROM file from sysfs fails. In this case,
the memory for the guest option ROM has been allocated so free that
memory by calling object_unparent(OBJECT(&s->dev.rom)) before
continuing.
Replace the error_report() and error_printf() messages for this case
when the option ROM cannot be read via sysfs with a suitable
info_report() message.
In the case when the host option ROM cannot be read via the sysfs
interface, xen_pt_register_regions() will attempt to setup the option
ROM for the guest the same way it would for any other Xen passthrough
PCI device that has an option ROM.
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- No changes to this patch in this version
Changes in v5:
- Shorten info_report message to resolve checkpatch line length warning
Changes in v4:
- v4 is the first version of the series that has this patch
This patch provides initial support for many newer Intel IGD devices
so, at least, guest creation will not fail if such newer Intel
IGD devices are passed through to a Xen HVM guest. But this patch
alone is not sufficient for proper operation of the Intel IGD
for many, if not all, of the newer Intel IGD devices when passed
through to a Xen HVM guest.
There are two main problems with more recent, modern devices:
1. The newer divices might require patches to the Intel OpRegion
and also an extended video bios table (VBT). Without support
for these aspects of the newer devices, the experience will
not be great and in many cases the Intel IGD still will not
function properly in the guest.
2. The newer devices only work with UEFI AFAICT, and the Ovmf*
platforms provided by the upsream edk2 project do not provide
support for the Intel IGD. It appears the problem is that the
ekd2 project deems the fact that the hardware manufacturer does
not provide the necessary firmware, the EFI graphics output
protocol (GOP) driver, in the ordinary way by making the EFI
GOP driver accessible in virtual environments via the option
ROM of the real PCI device, to be a reason to reject patches
that add support for the Intel IGD. This, however, is not a
fatal problem since it only affects the guest during early boot
when OVMF or the bootloader is running and the guest OS
graphics drivers have not yet been loaded. Lack of support
for the Intel IGD in OVMF does not seem to affect the experience
negatively once the guest OS graphics drivers have been loaded.
So efforts to address this problem are only important in cases
when it is necessary to get graphics output from OVMF and/or
the guest bootloader.
The last two patches in this patchset address these two problems.
Of those two patches, the first one is more necessary, and the
second of those two patches is only needed to provide graphics output
from the guest during early boot.
hw/xen/xen_pt_graphics.c | 7 +++++++
hw/xen/xen_pt_load_rom.c | 5 +----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index c5ab23e..c5c2d47 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -187,6 +187,13 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
return;
}
+ /* Case when the host ROM file from sysfs could not be read */
+ if (!bios_size) {
+ object_unparent(OBJECT(&s->dev.rom));
+ bios = NULL;
+ return;
+ }
+
if (bios_size < sizeof(struct rom_header)) {
error_setg(errp, "VGA: VBIOS image corrupt (too small)");
return;
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index 407b630..f136f13 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -77,10 +77,7 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
memset(ptr, 0xff, dev->romsize);
if (!fread(ptr, 1, st.st_size, fp)) {
- error_report("pci-assign: Cannot read from host %s", rom_file);
- error_printf("Device option ROM contents are probably invalid "
- "(check dmesg).\nSkip option ROM probe with rombar=0, "
- "or load from file with romfile=\n");
+ info_report("pci-assign: Can't read Option ROM %s from host", rom_file);
goto close_rom;
}
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 5/7] xen/igd: use igd header for IGD related definitions
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
` (3 preceding siblings ...)
2026-09-11 7:24 ` [PATCH v6 4/7] xen/igd: enable guest creation when ROM read fails Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 6/7] xen/igd: implement support for extended VBT Chuck Zmudzinski
` (2 subsequent siblings)
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
The newly added mocro definitions will be used in a later patch that adds
support for an extended video bios table (VBT) and are mostly derived from
the Linux kernel vfio driver for the Intel IGD.
Also rename XEN_PCI_INTEL_* -> XEN_PCI_IGD_* to make the names of the
macros related to Intel IGD more consistent.
No functional change intended.
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- v6 is the first version of the series that has this patch
hw/xen/xen_pt.h | 9 ---------
hw/xen/xen_pt_config_init.c | 8 ++++----
hw/xen/xen_pt_graphics.c | 16 ++++++----------
include/hw/xen/xen_igd.h | 16 ++++++++++++++++
4 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 095a0f0..ef93ac7 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -87,15 +87,6 @@ typedef int (*xen_pt_conf_byte_read)
#define XEN_PCI_CAP_MAX 48
-#define XEN_PCI_INTEL_OPREGION 0xfc
-
-#define XEN_PCI_IGD_DOMAIN 0
-#define XEN_PCI_IGD_BUS 0
-#define XEN_PCI_IGD_DEV 2
-#define XEN_PCI_IGD_FN 0
-#define XEN_PCI_IGD_SLOT_MASK \
- (1UL << PCI_SLOT(PCI_DEVFN(XEN_PCI_IGD_DEV, XEN_PCI_IGD_FN)))
-
typedef enum {
XEN_PT_GRP_TYPE_HARDWIRED = 0, /* 0 Hardwired reg group */
XEN_PT_GRP_TYPE_EMU, /* emul reg group */
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index bbc82a2..a708c82 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1808,7 +1808,7 @@ static const XenPTRegGroupInfo xen_pt_emu_reg_grps[] = {
},
/* Intel IGD Opregion group */
{
- .grp_id = XEN_PCI_INTEL_OPREGION,
+ .grp_id = XEN_PCI_IGD_OPREGION,
.grp_type = XEN_PT_GRP_TYPE_EMU,
.grp_size = 0x4,
.size_init = xen_pt_reg_grp_size_init,
@@ -2023,7 +2023,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp)
XenPTRegGroup *reg_grp_entry = NULL;
if (xen_pt_emu_reg_grps[i].grp_id != 0xFF
- && xen_pt_emu_reg_grps[i].grp_id != XEN_PCI_INTEL_OPREGION) {
+ && xen_pt_emu_reg_grps[i].grp_id != XEN_PCI_IGD_OPREGION) {
if (xen_pt_hide_dev_cap(&s->real_device,
xen_pt_emu_reg_grps[i].grp_id)) {
continue;
@@ -2036,7 +2036,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp)
}
}
- if (xen_pt_emu_reg_grps[i].grp_id == XEN_PCI_INTEL_OPREGION) {
+ if (xen_pt_emu_reg_grps[i].grp_id == XEN_PCI_IGD_OPREGION) {
if (!is_igd_vga_passthrough(&s->real_device) ||
s->real_device.vendor_id != PCI_VENDOR_ID_INTEL) {
continue;
@@ -2046,7 +2046,7 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error **errp)
* If an intel device is pass through we need to trap 0xfc,
* therefore the size should be 0xff.
*/
- reg_grp_offset = XEN_PCI_INTEL_OPREGION;
+ reg_grp_offset = XEN_PCI_IGD_OPREGION;
}
reg_grp_entry = g_new0(XenPTRegGroup, 1);
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index c5c2d47..be71989 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -12,8 +12,6 @@
static unsigned long igd_guest_opregion;
static unsigned long igd_host_opregion;
-#define XEN_PCI_INTEL_OPREGION_MASK 0xfff
-
typedef struct VGARegion {
int type; /* Memory or port I/O */
uint64_t guest_base_addr;
@@ -251,8 +249,6 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s)
return val;
}
-#define XEN_PCI_INTEL_OPREGION_PAGES 0x3
-#define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
{
int ret;
@@ -264,15 +260,15 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
}
/* We just work with LE. */
- xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
+ xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION,
(uint8_t *)&igd_host_opregion, 4);
- igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
- | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK);
+ igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_IGD_OPREGION_MASK)
+ | (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK);
ret = xc_domain_iomem_permission(xen_xc, xen_domid,
(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
- XEN_PCI_INTEL_OPREGION_PAGES,
- XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);
+ XEN_PCI_IGD_OPREGION_PAGES,
+ XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED);
if (ret) {
XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
@@ -285,7 +281,7 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
ret = xc_domain_memory_mapping(xen_xc, xen_domid,
(unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
- XEN_PCI_INTEL_OPREGION_PAGES,
+ XEN_PCI_IGD_OPREGION_PAGES,
DPCI_ADD_MAPPING);
if (ret) {
diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h
index da51f09..469171c 100644
--- a/include/hw/xen/xen_igd.h
+++ b/include/hw/xen/xen_igd.h
@@ -11,6 +11,22 @@
#ifndef XEN_IGD_H
#define XEN_IGD_H
+#define XEN_PCI_IGD_OPREGION 0xfc
+#define XEN_PCI_IGD_OPREGION_MASK 0xfff
+#define XEN_PCI_IGD_OPREGION_PAGES 0x3
+#define XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED 0x1
+#define XEN_PCI_IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
+#define XEN_PCI_IGD_VBT_SIGNATURE "$VBT"
+#define XEN_PCI_IGD_OPREGION_RVDA 0x3ba
+#define XEN_PCI_IGD_OPREGION_RVDS 0x3c2
+#define XEN_PCI_IGD_OPREGION_VERSION 0x16
+#define XEN_PCI_IGD_DOMAIN 0
+#define XEN_PCI_IGD_BUS 0
+#define XEN_PCI_IGD_DEV 2
+#define XEN_PCI_IGD_FN 0
+#define XEN_PCI_IGD_SLOT_MASK \
+ (1UL << PCI_SLOT(PCI_DEVFN(XEN_PCI_IGD_DEV, XEN_PCI_IGD_FN)))
+
#include "hw/xen/xen-host-pci-device.h"
typedef struct XenPCIPassthroughState XenPCIPassthroughState;
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 6/7] xen/igd: implement support for extended VBT
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
` (4 preceding siblings ...)
2026-09-11 7:24 ` [PATCH v6 5/7] xen/igd: use igd header for IGD related definitions Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-13 15:30 ` Chuck Zmudzinski
2026-09-11 7:24 ` [PATCH v6 7/7] xen/igd: use custom option ROM if provided Chuck Zmudzinski
2026-09-13 15:27 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
7 siblings, 1 reply; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
The current implementation of support for Intel IGD passthrough to a Xen HVM
guest relies on directly mapping the host OpRegion to the guest, and although
the OpRegion is 2 pages in size, it is not always page-aligned so an extra
page needs to be mapped to fully map it to the guest. This results in an extra
page of host memory mapped into the guest that should remain confidential to
the host. This is also why XEN_PCI_IGD_OPREGION_PAGES is currently set to 3
even though the size of the OpRegion is only 2 pages. So in this new
implementation avoid this confusion by redefining XEN_PCI_IGD_OPREGION_PAGES
to 2, the actual size of the OpRegion.
The current implementation also does not foresee the possibility that the
video bios table (VBT) might not be embedded as part of the 2-page OpRegion
but instead added on as an extended region beyond the 2 pages of the OpRegion.
In such cases, the 3 pages that are mapped in the current implementation are
not enough to hold both the OpRegion and the extended VBT.
The current implementation of support for Intel IGD passthrough to a Xen HVM
guest also relies on a position-independent OpRegion so the unmodified host
OpRegion can be mapped to a different address in the guest. However, as
indicated in the Link tags below referencing support for the Intel IGD in the
Linux kernel vfio driver, since the addition of devices with an extended VBT
the OpRegion is not always position-independent. That is, when the OpRegion
for such a device is mapped in the guest at a different address, it will not
work correctly in the guest. This position-dependent behavior arises from the
fact that the the address of an extended VBT is stored in the OpRegion in the
RVDA field of the OpRegion and in some cases that address is an absolute
address, not an address relative to the OpRegion base address, and in other
cases the extended VBT is not contiguous after the OpRegion in the host so in
such cases even a relative RVDA address would need to be adjusted for the
OpRegion to be compatible with the desired memory map in the guest where the
extended VBT would be contiguous with the OpRegion.
To overcome these problems, this new implementation exposes an emulated
OpRegion and VBT to the guest instead of directly mapping the host OpRegion to
the guest and also implements a protocol for communication between hvmloader
and Qemu so both the device model and hvmloader agree on the number of pages
to reserve for the OpRegion and VBT which varies depending on the size of
the extended VBT instead of being the constant value of 3 as in the current
implementation. In this new implemetation, Qemu reads the host OpRegion to
determine if there is an extended VBT and if so, how large it is and how many
pages are needed in the guest E820 map to accomodate both the OpRegion and
extended VBT. Also, in this new implementation, Qemu zero-pads the extraneous
memory in the areas before or after a non-page-aligned OpRegion or VBT to
avoid exposing memory to the guest that should be confidential to the host.
This implementation depends on compatible support in hvmloader and also
provides for backward compatibility and fallback to the old protocol when
either hvmloader or Qemu cannot fulfill the requirements of this new protocol.
This new protocol begins as follows: Before writing a value to the register
that stores the address of the OpRegion that Intel has defined as the ASLS
register and is identified in Qemu code as XEN_PCI_IGD_OPREGION, hvmloader
reads from the ASLS register and Qemu, in the case when Qemu detects a read
of the ASLS register before a write to the ASLS register, returns the number
of pages that hvmloader needs to reserve for the OpRegion and VBT in the guest
E820 map. With that information, hvmloader computes the address of the page
base of the OpRegion in the guest and writes that value to the ASLS register.
Then Qemu responds to this write to the ASLS register by computing the correct
value for the ASLS register so that future reads of the ASLS register return
that value to the guest. Qemu also responds to this write by constructing the
OpRegion and VBT for the guest, patching the RVDA value in the OpRegion if
necessary, and making the OpRegion and VBT a single continuous region
accessible to the guest at the address stored in the ASLS register using
Qemu's ioreq server.
If for any reason Qemu is unable to access the host OpRegion and is also
therefore unable to determine if there is an extended VBT and also unable to
compute how many pages are needed for the OpRegion and extended VBT, Qemu
falls back to the old protocol and direct maps the 3 pages from the host to
the guest that are needed to fully map a non-page-aligned host OpRegion. In
this case Qemu also returns 0 instead of the number of pages to reserve in the
E820 map which communicates to hvmloader that hvmloader should fall back to
the old protocol and assume 3 pages for the OpRegion and expect Qemu to
directly map the host OpRegion rather than expose an emulated OpRegion and VBT
using Qemu's ioreq server.
Qemu can fail to access the host OpRegion because Qemu's access to the host
OpRegion depends on Linux kernel support for this. Typically the Linux kernel
exposes device IO regions in the Linux sysfs filesystem, but in the case of
the OpRegion and VBT, these regions are only exposed in the Linux debugfs and
then only when the Intel IGD is bound to the i915 driver. This means that Qemu
does not have access to the OpRegion and VBT via the debugfs when the Intel
IGD is bound to the xen-pciback driver. So it is necessary that the OpRegion
and VBT be placed into the host filesystem where Qemu can access them when
the Intel IGD is bound to the xen-pciback driver. In this implementation,
the OpRegion and VBT files are searched for in files named "intel-opregion"
and "intel-vbt" in the directories configured by Qemu as firmware directories.
These files can be automatically placed into a suitable location in the host
filesystem when the Intel IGD is made assignable to a Xen guest with a
suitable patch to libxl or they can be manually placed into the host
filesystem by copying them from the debugfs to the "intel-opregion" and
"intel-vbt" files located in an appropriate Qemu firmware directory when the
Intel IGD is bound to the Linux kernel i915 driver. Assuming the Intel IGD is
at dri0 when bound to the Linux kernel i915 driver, the files in the debugfs
where the OpRegion and VBT are exposed on the host can be found at
/sys/kernel/debug/dri/0/i915_opregion
and
/sys/kernel/debug/dri/0/i915_vbt, respectively.
Another case that can occur is when hvmloader lacks support for this new
protocol. Qemu detects this case when hvmloader writes to the ASLS register
before the guest reads the register. In this case Qemu assumes hvmloader lacks
support for allocating more than 3 pages for the OpRegion so Qemu in this case
falls back to the old protocol of direct mapping the 3 host pages to the guest
that are needed to fully map a non-page-aligned host OpRegion to the guest.
This new protocol also requires that after Qemu makes the OpRegion and VBT
accessible to the guest via its ioreq server, hvmloader makes a copy of the
OpRegion and VBT and writes the address of the OpRegion back to the ASLS
register. Qemu responds to this second write of the OpRegion address to the
ASLS register by unmapping the pages containing the OpRegion and VBT from the
ioreq server. This makes it possible for hvmloader to back the pages that
store the OpRegion and VBT with RAM allocated to the guest. This last part of
the protocol is required to support Windows guests because testing indicates
the Windows graphics drivers are unable to access the OpRegion and VBT when
the OpRegion and VBT are exposed to the guest via Qemu's ioreq server, while
the Windows graphics drivers are able to access the OpRegion and VBT when the
pages that store them are backed by RAM allocated to the guest. After the
second write to the ASLS register which causes Qemu to unmap the OpRegion and
VBT from the ioreq server, Qemu ignores all subsequent writes to the ASLS
register from the guest. In this way the Windows IGD graphics drivers work
as expected.
Also ensure that in xen_pt_unregister_vga_regions the call to unmap the
OpRegion is only made in cases when we fall back to direct mapping of the
host OpRegion. We could keep the constant 3 for the number of pages to unnap
there since the number of pages to unmap will always be 3, but instead we use
the value of opregion_vbt_pages there which also will always be 3 when we fall
back to direct mapping of the host OpRegion to the guest.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=bab2c1990b78
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/vfio/pci/vfio_pci_igd.c?id=49ba1a2976c8
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
The comapnion patch to hvmloader will be posted to the xen-devel and qemu-devel
mailing lists shortly after this patch is posted. It is v3 of the patch
"tools/hvmloader: implement Intel IGD extended VBT support". Please note that
previous versions of that patch to hvmloader are not compatible with this
patch.
Changes in v6:
- After considering comments on v2 of the companion patch to hvmloader, this
patch has been totally re-worked. The work of reading the OpRegion,
discovering if there is an extended VBT and how many pages of memory are
needed to accomodate it, and patching the OpRegion if necessary, has been
moved from hvmloader to Qemu since v5. There are some simplifications,
such as the bitmask to communicate if extended VBT and OpRegion 2+ is
supported has been replaced with a simpler protocol that involves Qemu
noticing if the guest reads the OpRegion register before writing to it
and hvmloader noticing if Qemu returns 0 or the number of pages needed for
the OpRegion and VBT if hvmloader reads the OpRegion register before
writing to it. Another simplification is that the complicated
communication protocol with four extra writes to the OpRegion register
has been mostly removed and replaced with ontly two writes, with the
reason for the second write explained below.
- All the code that involves reading the OpRegion, discovering if there is
a VBT, how many pages are needed for the OpRegion + VBT, and patching the
OpRegion if necessary has been moved from hvmloader to Qemu.
- In contrast to v5 and the current implementation, the host OpRegion is
never directly exposed to the guest. Instead, an emulated copy, patched if
necessary, is exposed to the guest using Qemu's ioreq server.
- Because Windows IGD drivers cannot access the OpRegion and VBT when it is
exposed to the guest by the ioreq server, a second write to the OpRegion
register from hvmloader is processed by Qemu to indicate to Qemu that the
OpRegion and VBT must be unmapped from the ioreq server which allows
hvmloader to configure the guest to use its own copy of the OpRegion + VBT
that is backed by guest RAM. With this configuration in place, both
Windows and Linux guests are able to access the OpRegion and VBT and work
as expected.
Changes in v5:
- fix style by adding braces to two if blocks and not initializing
two static boolean variables to false
- update the link to the companion patch for Xen hvmloader
Changes in v4:
- v4 is the first version of the series that has this patch
hw/xen/xen_pt_graphics.c | 266 +++++++++++++++++++++++++++++++++++++--
include/hw/xen/xen_igd.h | 2 +-
2 files changed, 257 insertions(+), 11 deletions(-)
diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c
index be71989..7136669 100644
--- a/hw/xen/xen_pt_graphics.c
+++ b/hw/xen/xen_pt_graphics.c
@@ -4,13 +4,27 @@
#include "qemu/osdep.h"
#include "qemu/error-report.h"
#include "qapi/error.h"
+#include "qemu/datadir.h"
#include "hw/xen/xen_pt.h"
#include "hw/xen/xen_igd.h"
+#include "hw/xen/xen-hvm-common.h"
#include "xen-host-pci-device.h"
#include "system/physmem.h"
static unsigned long igd_guest_opregion;
static unsigned long igd_host_opregion;
+static uint8_t *opregion_vbt; /* pointer to OpRegion + VBT */
+/*
+ * If there is an extended VBT or if the OpRegion is not aligned on a page
+ * boundary, we will need extra pages for the OpRegion + VBT.
+ */
+static unsigned int extra_opregion_pages;
+static unsigned long opregion_vbt_pages; /* # of pages for OpRegion + VBT */
+static uint16_t version; /* OpRegion version */
+static uint32_t rvds; /* VBT size */
+static unsigned long rvda_host; /* VBT address in host */
+static bool opregion_is_direct_mapped;
+MemoryRegion mr_opregion;
typedef struct VGARegion {
int type; /* Memory or port I/O */
@@ -115,12 +129,11 @@ int xen_pt_unregister_vga_regions(XenHostPCIDevice *dev)
}
}
- if (igd_guest_opregion) {
+ if (opregion_is_direct_mapped && igd_guest_opregion) {
ret = xc_domain_memory_mapping(xen_xc, xen_domid,
(unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
- 3,
- DPCI_REMOVE_MAPPING);
+ opregion_vbt_pages, DPCI_REMOVE_MAPPING);
if (ret) {
return ret;
}
@@ -237,8 +250,158 @@ void xen_pt_setup_vga(XenPCIPassthroughState *s, XenHostPCIDevice *dev,
uint32_t igd_read_opregion(XenPCIPassthroughState *s)
{
+ char opregion_file[64], vbt_file[64];
+ FILE *fp = NULL;
+ struct stat st;
+ uint8_t *opregion = NULL, *vbt = NULL;
+ void *ptr = NULL;
uint32_t val = 0;
+ if (!igd_host_opregion) {
+ /* We just work with LE. */
+ xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION,
+ (uint8_t *)&igd_host_opregion, 4);
+
+ g_autofree const char *fname1 = g_strdup("intel-opregion");
+ g_autofree const char *path1 = qemu_find_file(QEMU_FILE_TYPE_BIOS,
+ fname1);
+ /*
+ * If getting the OpRegion or VBT from the host filesystem fails,
+ * fallback to direct mapping of the host OpRegion to the guest.
+ */
+ if (!path1) {
+ XEN_PT_WARN(&s->dev, "OpRegion host file \"%s\" not found\n",
+ fname1);
+ goto fallback;
+ }
+ snprintf(opregion_file, sizeof(opregion_file), "%s", path1);
+ fp = fopen(opregion_file, "r");
+ if (fp == NULL) {
+ if (errno != ENOENT) {
+ XEN_PT_WARN(&s->dev, "Cannot open %s: %s\n",
+ opregion_file, strerror(errno));
+ }
+ goto fallback;
+ }
+ if (fstat(fileno(fp), &st) == -1) {
+ XEN_PT_WARN(&s->dev, "Cannot stat %s: %s\n",
+ opregion_file, strerror(errno));
+ goto fallback;
+ }
+ if (st.st_size != XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT) {
+ XEN_PT_WARN(&s->dev, "Invalid OpRegion size (%u)\n", st.st_size);
+ goto fallback;
+ }
+ opregion = g_new0(uint8_t, st.st_size);
+ ptr = (void *)opregion;
+ if (fread(ptr, 1, st.st_size, fp) != st.st_size) {
+ XEN_PT_WARN(&s->dev, "Can't read host OpRegion %s\n",
+ opregion_file);
+ goto fallback;
+ }
+ if (memcmp(ptr, XEN_PCI_IGD_OPREGION_SIGNATURE, 16)) {
+ XEN_PT_WARN(&s->dev, "Invalid OpRegion signature\n");
+ goto fallback;
+ }
+ fclose(fp);
+
+ version = *(uint16_t *)(opregion +
+ XEN_PCI_IGD_OPREGION_VERSION);
+ XEN_PT_LOG(&s->dev, "OpRegion version: 0x%x\n", version);
+ if (version >= 0x0200) {
+ rvda_host = *(unsigned long *)(opregion +
+ XEN_PCI_IGD_OPREGION_RVDA);
+ /* It is convenient to make rvda_host absolute */
+ if (version > 0x0200) {
+ rvda_host += igd_host_opregion;
+ }
+ XEN_PT_LOG(&s->dev, "host VBT address: 0x%lx\n", rvda_host);
+ rvds = *(uint32_t *)(opregion +
+ XEN_PCI_IGD_OPREGION_RVDS);
+ XEN_PT_LOG(&s->dev, "VBT size: 0x%x\n", rvds);
+ }
+
+ if (rvds && rvda_host) {
+ g_autofree const char *fname2 = g_strdup("intel-vbt");
+ g_autofree const char *path2 = qemu_find_file(QEMU_FILE_TYPE_BIOS,
+ fname2);
+ if (!path2) {
+ XEN_PT_WARN(&s->dev, "VBT host file \"%s\" not found\n",
+ fname2);
+ goto fallback;
+ }
+ snprintf(vbt_file, sizeof(vbt_file), "%s", path2);
+ fp = fopen(vbt_file, "r");
+ if (fp == NULL) {
+ if (errno != ENOENT) {
+ XEN_PT_WARN(&s->dev, "Cannot open %s: %s\n",
+ vbt_file, strerror(errno));
+ }
+ goto fallback;
+ }
+ if (fstat(fileno(fp), &st) == -1) {
+ XEN_PT_WARN(&s->dev, "Cannot stat %s: %s\n",
+ vbt_file, strerror(errno));
+ goto fallback;
+ }
+ if (st.st_size != rvds) {
+ XEN_PT_WARN(&s->dev, "Invalid VBT size (%u)\n", st.st_size);
+ goto fallback;
+ }
+ vbt = g_new0(uint8_t, st.st_size);
+ ptr = (void *)vbt;
+ if (fread(ptr, 1, st.st_size, fp) != st.st_size) {
+ XEN_PT_WARN(&s->dev, "Can't read host VBT %s\n",
+ vbt_file);
+ goto fallback;
+ }
+ if (memcmp(ptr, XEN_PCI_IGD_VBT_SIGNATURE, 4)) {
+ XEN_PT_WARN(&s->dev, "Invalid VBT signature\n");
+ goto fallback;
+ }
+ fclose(fp);
+ extra_opregion_pages = rvds >> XC_PAGE_SHIFT;
+ if (rvds & XEN_PCI_IGD_OPREGION_MASK) {
+ extra_opregion_pages++;
+ }
+ if (((igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK) +
+ (rvds & XEN_PCI_IGD_OPREGION_MASK)) >
+ (1 << XC_PAGE_SHIFT)) {
+ extra_opregion_pages++;
+ }
+ } else {
+ rvda_host = 0;
+ rvds = 0;
+ if (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK) {
+ extra_opregion_pages = 1;
+ }
+ }
+
+ opregion_vbt_pages = XEN_PCI_IGD_OPREGION_PAGES +
+ extra_opregion_pages;
+ opregion_vbt = g_new0(uint8_t,
+ opregion_vbt_pages << XC_PAGE_SHIFT);
+ ptr = (void *)(opregion_vbt +
+ (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK));
+ memcpy(ptr, (void *)opregion,
+ XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT);
+ if (rvds) {
+ ptr += (XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT);
+ memcpy(ptr, (void *)vbt, rvds);
+ }
+ g_free(opregion);
+ g_free(vbt);
+ /*
+ * By returning the size of the OpRegion + VBT here instead of 0, we
+ * indicate to hvmloader that we support an extended VBT and we give
+ * hvmloader the information it needs to place the OpRegion + VBT in
+ * the E820 map. Also, in this case the guest read the OpRegion
+ * register before writing to it, which means the guest supports
+ * an extended VBT.
+ */
+ return opregion_vbt_pages;
+ }
+
if (!igd_guest_opregion) {
return val;
}
@@ -247,11 +410,38 @@ uint32_t igd_read_opregion(XenPCIPassthroughState *s)
XEN_PT_LOG(&s->dev, "Read opregion val=%x\n", val);
return val;
+
+fallback:
+ XEN_PT_LOG(&s->dev, "Fallback to host OpRegion mapping\n");
+ opregion_is_direct_mapped = true;
+ if (fp) {
+ fclose(fp);
+ }
+ g_free(opregion);
+ g_free(vbt);
+ return val;
}
void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
{
int ret;
+ static bool opregion_is_ioreq_mapped;
+ static unsigned long igd_guest_opregion_pgbase;
+
+ if (opregion_is_ioreq_mapped && (val == igd_guest_opregion)) {
+ /*
+ * To support Windows IGD drivers that don't work with the OpRegion
+ * and VBT when they are mapped to an ioreq server, hvmloader writes
+ * the value of igd_guest_opregion a second time to signal it is time
+ * to unmap the OpRegion from the ioreq server. Hvmloader has made
+ * a copy of the OpRegion and will configure the guest to use its
+ * copy. In this way, the Windows IGD drivers work as expected.
+ */
+ memory_region_del_subregion(get_system_memory(), &mr_opregion);
+ object_unparent(OBJECT(&mr_opregion));
+ opregion_is_ioreq_mapped = false;
+ XEN_PT_LOG(&s->dev, "Successfully configured emulated OpRegion\n");
+ }
if (igd_guest_opregion) {
XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring %x\n",
@@ -259,16 +449,73 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
return;
}
- /* We just work with LE. */
- xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION,
- (uint8_t *)&igd_host_opregion, 4);
+ if (!igd_host_opregion) {
+ /* We just work with LE. */
+ xen_host_pci_get_block(&s->real_device, XEN_PCI_IGD_OPREGION,
+ (uint8_t *)&igd_host_opregion, 4);
+ opregion_is_direct_mapped = true;
+ }
igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_IGD_OPREGION_MASK)
| (igd_host_opregion & XEN_PCI_IGD_OPREGION_MASK);
+ igd_guest_opregion_pgbase = igd_guest_opregion &
+ ~XEN_PCI_IGD_OPREGION_MASK;
+
+ if (opregion_is_direct_mapped) {
+ XEN_PT_LOG(&s->dev, "hvmloader lacks extended VBT support, "
+ "continuing with legacy support only\n");
+ /*
+ * In this case we need to direct map the OpRegion because either we
+ * failed to get a copy of the OpRegion from the host filesystem or
+ * the guest does not support an extended VBT. In this case we also
+ * assume we need an extra page because the OpRegion is not always
+ * aligned on a page boundary.
+ */
+ extra_opregion_pages = 1;
+ opregion_vbt_pages = XEN_PCI_IGD_OPREGION_PAGES +
+ extra_opregion_pages;
+ goto map;
+ } else {
+ Object *owner = OBJECT(&s->dev);
+ unsigned long rvda_guest = 0; /* VBT address in guest */
+
+ /* Compute rvda value for the guest */
+ if (rvds && (version > 0x0200)) {
+ if (version == 0x0200) {
+ rvda_guest = igd_guest_opregion +
+ (XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT);
+ } else {
+ /* Convert to relative address */
+ rvda_guest = XEN_PCI_IGD_OPREGION_PAGES << XC_PAGE_SHIFT;
+ rvda_host -= igd_host_opregion;
+ }
+ }
+
+ /* Patch the OpRegion with the correct rvda value for the guest */
+ if (rvds && (rvda_guest != rvda_host)) {
+ *(unsigned long *)(opregion_vbt + (igd_guest_opregion &
+ XEN_PCI_IGD_OPREGION_MASK) +
+ XEN_PCI_IGD_OPREGION_RVDA) = rvda_guest;
+ XEN_PT_LOG(&s->dev, "Patched OpRegion with guest rvda = 0x%lx\n",
+ rvda_guest);
+ }
+
+ /* Configure ioreq server for the emulated OpRegion */
+ memory_region_init_ram(&mr_opregion, owner, "xen.intel.opregion",
+ opregion_vbt_pages << XC_PAGE_SHIFT,
+ &error_fatal);
+ memory_region_add_subregion(get_system_memory(),
+ igd_guest_opregion_pgbase, &mr_opregion);
+ void *ptr = memory_region_get_ram_ptr(&mr_opregion);
+ memcpy(ptr, (void *)opregion_vbt, opregion_vbt_pages << XC_PAGE_SHIFT);
+ g_free(opregion_vbt);
+ opregion_is_ioreq_mapped = true;
+ return;
+ }
+map:
ret = xc_domain_iomem_permission(xen_xc, xen_domid,
(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
- XEN_PCI_IGD_OPREGION_PAGES,
- XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED);
+ opregion_vbt_pages, XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED);
if (ret) {
XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
@@ -281,8 +528,7 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
ret = xc_domain_memory_mapping(xen_xc, xen_domid,
(unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
(unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
- XEN_PCI_IGD_OPREGION_PAGES,
- DPCI_ADD_MAPPING);
+ opregion_vbt_pages, DPCI_ADD_MAPPING);
if (ret) {
XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
diff --git a/include/hw/xen/xen_igd.h b/include/hw/xen/xen_igd.h
index 469171c..e66b3a3 100644
--- a/include/hw/xen/xen_igd.h
+++ b/include/hw/xen/xen_igd.h
@@ -13,7 +13,7 @@
#define XEN_PCI_IGD_OPREGION 0xfc
#define XEN_PCI_IGD_OPREGION_MASK 0xfff
-#define XEN_PCI_IGD_OPREGION_PAGES 0x3
+#define XEN_PCI_IGD_OPREGION_PAGES 0x2
#define XEN_PCI_IGD_OPREGION_ENABLE_ACCESSED 0x1
#define XEN_PCI_IGD_OPREGION_SIGNATURE "IntelGraphicsMem"
#define XEN_PCI_IGD_VBT_SIGNATURE "$VBT"
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* [PATCH v6 7/7] xen/igd: use custom option ROM if provided
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
` (5 preceding siblings ...)
2026-09-11 7:24 ` [PATCH v6 6/7] xen/igd: implement support for extended VBT Chuck Zmudzinski
@ 2026-09-11 7:24 ` Chuck Zmudzinski
2026-09-13 15:27 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-11 7:24 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
Since in some cases the option ROM is not readable from sysfs
on the host, provide the option to use a custom option ROM file
instead that, for example, could be extracted from BIOS or UEFI
firmware and modified as needed for use with a particular Intel
IGD device.
The file must be named "igd.rom" and be located in a directory
configured at build time as a Qemu firmware directory and its
size should be a power of two, and it must be compatible with
the particular Intel IGD device being passed through.
If provided, the "igd.rom" file will be used as the option ROM
instead of the option ROM file epxosed in the host sysfs.
If no "igd.rom" file is provided, this patch has no effect.
Signed-off-by: Chuck Zmudzinski <brchuckz@aol.com>
---
Changes in v6:
- Added a link to Tomita's edk2 patches for the OvmfX64 platform
for KVM/VFIO guests in this additional notes section
Changes in v5:
- Fix wrong whitespace in three places in a conditional block
Changes in v4:
- v4 is the first version of the series that has this patch
Sorry for the length of these notes but there are many things
to say about this patch that are not obvious to persons without
some experience of actually trying to use the option ROM of an
Intel IGD when it is passed through to a Xen HVM guest.
This patch is primarily for providing a way to add Intel IGD
support for the OvmfXen platform to get graphics output during
early boot from modern Intel IGD devices that are only compatible
with UEFI for graphics output during early boot.
Note this patch is not necessary for successful operation of the
Intel IGD in the guest once the guest OS drivers have loaded. It
is only needed as part of the patchset necessary to provide
graphics output from the Intel IGD in the guest during early
boot when using newer devices that are only compatible with UEFI
for graphics output during early boot. Most older devices that are
compatible with legacy VGA BIOS will work with Seabios without
this patch, but they will need Patch 3 of this patchset to work
with Seabios.
Some notes on adding Intel IGD support for the OvmfXen platform:
It is necessary to provide an EFI graphics output protocol (GOP)
driver to the guest to get output from the Intel IGD before the
guest OS loads the graphics drivers when the guest uses UEFI.
This GOP driver is essentially the replacement of the VBIOS
driver that applied to older devices that use legacy bios, as
described here:
https://www.intel.com/content/www/us/en/support/articles/000005749/graphics.html
Unfortunately, with modern Intel IGD devices, the EFI GOP driver
is not provided to the guest in the usual way of providing firmware
for a PCI device in the option ROM of the real PCI device. So I
included this patch in this patchset to provide a way to expose
the EFI GOP driver to the guest. I was able to extract the
GOP driver for my device using the UEFI bios update file from
the motherboard manufacturer and the UEFITool available here:
https://github.com/longsoft/uefitool
That EFI driver can be wrapped into an option ROM using the
EfiRom bin wrapper that is part of the edk2 project:
https://github.com/tianocore/edk2/blob/master/BaseTools/BinWrappers/PosixLike/EfiRom
I tried setting the 'romfile' member of the PCIDevice struct that
is used by KVM/VFIO Qemu devices and emulated Qemu PCI devices, but
that did not work with Xen PCI passthrough devices. Neither Seabios
nor the OvmfXen platform could detect the option ROM in the guest
with that method of exposing an option ROM to the guest. So I
implemented this approach of substituting the 'rom' file exposed by
sysfs with an administrator-provided file instead of using 'romfile'.
In the commit message I mentioned the size of the rom file "should"
be a power of two. I mentioned this because the code in pci.c that
handles the 'romfile' setting for PCI devices enforces this
requirement strictly on the romfile that Qemu emulated or VFIO
devices use. However, I do not know for sure whether or not the rom
file is strictly required to have a size of a power of two, so that
is why I say it should be a power of two. In my testing, I zero pad
the "igd.rom" file so it has a size of a power of two. I will accept
the suggestions of experts on this question about the appropriate size
of the option ROM file (I am not such an expert!).
As mentioned in the message accompanying Patch 4 of this patchset,
the official edk2 project does not provide support for the Intel
IGD, but some OVMF patches for Intel IGD support are available
online for KVM/VFIO guests, such as at the links below (they apply
to the OvmfPkgX64 platform):
https://github.com/tomitamoeko/VfioIgdPkg
https://github.com/cmd2001/build-edk2-gvtd
https://eci.intel.com/docs/3.3/components/kvm-hypervisor.html#build-ovmf-fd-for-kvm
https://github.com/LongQT-sea/intel-igpu-passthru
With such patches it is reported that the passed through Intel
IGD device lights up the display during early boot from OVMF
and the guest bootloader in KVM/VFIO guests provided that the
administrator provides the correct ROM file via the 'romfile'
setting for the passed thorugh Intel iGD device and applies
appropriate patches to the OvmfPkgX64 platform.
It should also be possible to add Intel IGD support for the OvmfXen
platform also but I have not seen any such patches online for OvmfXen
and if anyone knows of such patches online I would be interested to
be informed about them. I am also working on my own patches to
add Intel IGD support to the OvmfXen platform, in private for now.
If anyone is interested, I can make the work I have done so far
toward this goal avalable online.
hw/xen/xen_pt_load_rom.c | 47 +++++++++++++++++++++++++++-------------
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/hw/xen/xen_pt_load_rom.c b/hw/xen/xen_pt_load_rom.c
index f136f13..ab448f4 100644
--- a/hw/xen/xen_pt_load_rom.c
+++ b/hw/xen/xen_pt_load_rom.c
@@ -2,6 +2,7 @@
* This is splited from hw/i386/kvm/pci-assign.c
*/
#include "qemu/osdep.h"
+#include "qemu/datadir.h"
#include "qapi/error.h"
#include "qemu/error-report.h"
#include "hw/pci/pci.h"
@@ -13,9 +14,9 @@
* need to be modified.
*
* For such cases, use this function to get a pointer to the option ROM
- * from sysfs. Caller has the responsibility to edit the option ROM as
- * needed, call pci_register_bar to register the modified option ROM,
- * and set has_rom to true for the PCI device.
+ * from a user provided romfile or sysfs. Caller has the responsibility
+ * to edit the option ROM as needed, call pci_register_bar to register
+ * the modified option ROM, and set has_rom to true for the PCI device.
*
* This function must be called before xen_pt_register_regions is called
* because if xen_pt_register_regions is called first, it will register
@@ -32,17 +33,27 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
struct stat st;
void *ptr = NULL;
Object *owner = OBJECT(dev);
+ g_autofree const char *fname = g_strdup("igd.rom");
+ g_autofree const char *path = qemu_find_file(QEMU_FILE_TYPE_BIOS, fname);
+ bool sysfs = false;
/* If loading ROM from file, pci handles it */
if (dev->romfile || !dev->rom_bar) {
return NULL;
}
- snprintf(rom_file, sizeof(rom_file),
- "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
- domain, bus, slot, function);
+ if (path) {
+ snprintf(rom_file, sizeof(rom_file), "%s", path);
+ XEN_PT_LOG(dev, "Using Intel IGD romfile %s "
+ "(administratior provided)\n", path);
+ } else {
+ snprintf(rom_file, sizeof(rom_file),
+ "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
+ domain, bus, slot, function);
+ sysfs = true;
+ XEN_PT_LOG(dev, "Using Intel IGD romfile from host sysfs\n");
+ }
- /* Write "1" to the ROM file to enable it */
fp = fopen(rom_file, "r+");
if (fp == NULL) {
if (errno != ENOENT) {
@@ -55,10 +66,14 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
goto close_rom;
}
- val = 1;
- if (fwrite(&val, 1, 1, fp) != 1) {
- goto close_rom;
+ /* Write "1" to the ROM file to enable it if using ROM from sysfs */
+ if (sysfs) {
+ val = 1;
+ if (fwrite(&val, 1, 1, fp) != 1) {
+ goto close_rom;
+ }
}
+
fseek(fp, 0, SEEK_SET);
if (dev->romsize != UINT_MAX) {
@@ -83,11 +98,13 @@ void *pci_assign_dev_load_option_rom(PCIDevice *dev,
*size = st.st_size;
close_rom:
- /* Write "0" to disable ROM */
- fseek(fp, 0, SEEK_SET);
- val = 0;
- if (!fwrite(&val, 1, 1, fp)) {
- XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+ /* Write "0" to disable ROM if using ROM from sysfs */
+ if (sysfs) {
+ fseek(fp, 0, SEEK_SET);
+ val = 0;
+ if (!fwrite(&val, 1, 1, fp)) {
+ XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
+ }
}
fclose(fp);
--
2.52.0
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough
2026-09-11 7:24 ` [PATCH v6 0/7] xen/igd: fixes for Intel IGD passthrough Chuck Zmudzinski
` (6 preceding siblings ...)
2026-09-11 7:24 ` [PATCH v6 7/7] xen/igd: use custom option ROM if provided Chuck Zmudzinski
@ 2026-09-13 15:27 ` Chuck Zmudzinski
7 siblings, 0 replies; 10+ messages in thread
From: Chuck Zmudzinski @ 2026-09-13 15:27 UTC (permalink / raw)
To: qemu-devel
Cc: qemu-stable, xen-devel, Stefano Stabellini, Anthony PERARD,
Edgar E . Iglesias, Tomita Moeko
On 9/11/2026 3:24 AM, Chuck Zmudzinski wrote:
> Please note that Patch 6 of this series requires a patch to hvmloader of
> Xen for the new support to take effect. Also please note that earlier
> versions of the patch to hvmloader are not compatible with this version
> of Patch 6. Please look for v3 of the "tools/hvmloader: implement Intel IGD
> extended VBT support" patch that will be posted shortly to both the xen-devel
> and qemu-devel mailing lists.
The patch to hvmloader required by Patch 6 of this patch series has been
upgraded to v4 and is available here:
https://lore.kernel.org/xen-devel/20260913032724.62438-2-brchuckz@aol.com/
^ permalink raw reply [flat|nested] 10+ messages in thread