Re: [PATCH] tools/hvmloader: implement Intel IGD extended VBT support

On 7/31/2026 8:03 PM, Chuck Zmudzinski wrote:
> Modern Intel IGD devices do not work well with the current
> implementation of support for the Intel IGD in hvmloader because
> it lacks support for an extended video bios table (VBT).
> 
> Code 43 errors in Windows guests and failure of the guest screen
> to light up are some of the problems that occur with the
> current implementation.
> 
> To address this problem, this patch implements support for
> Intel IGD devices with an extended VBT and OpRegion version 2
> and higher which is required for most modern Intel IGD devices.
> 
> This patch also depends on compatible support in the device
> model. If hvmloader detects the device model lacks such support,
> it will fall back to the currently implemented protocol for
> configuring the OpRegion to provide backward compatibiltiy for
> systems that lack a device model with support for an extended VBT.
> 
> Support for an extended VBT is implemented in the newly introduced
> function opregion_setup() which is implemented in the new file
> intel_opregion.c.
> 
> Major differences between this implementation and the current
> implemntation that only supports older devices without an
> extended VBT:
> 
> 1. The current implemntation reserves a constant number of
>    pages (3) in the E820 map for the OpRegion which is set by
>    the IGD_OPREGION_PAGES macro in the current implementation.
>    With OpRegion 2 and higher, the OpRegion can have an
>    extended VBT that must be provided to the guest with the
>    OpRegion. This means the size of the region is not fixed,
>    so in this new implementation the IGD_OPREGION_PAGES constant
>    is changed to a variable in e820.c, igd_opregion_e820_pages,
>    that is set to its proper value based on the the size of the
>    VBT. In this new implemntation, the size of the ACPI NVS region
>    reserved for the OpRegion in the E820 map is equal to the value
>    of the igd_opregion_e820_pages variable instead of being set
>    to the constant value determined by IGD_OPREGION_PAGES.
> 
> 2. The current implemntation provides the guest with access
>    to the unmodified OpRegion on the host via memory mapping
>    from the host to the guest. This is insufficient for
>    OpRegion 2 and higher because some devices will require
>    modifications to the OpRegion for proper operation in the
>    guest. So this new implementation provides hvmloader with a
>    copy of the host's OpRegion that hvmloader can modify as
>    needed for proper operation. Mapping the OpRegion from the
>    host to the guest is only used temporarily during setup of
>    the OpRegion by hvmloader and once hvmloader has a copy of
>    the OpRegion and the extended VBT, the device model removes
>    the host mapping and hvmloader configures the guest to use
>    the guest's possibly modified copy of the OpRegion instead.
> 
> 3. The current implementation lacks useful debugging information
>    for the more recent devices. This new implementation provides
>    useful debugging output from hvmloader, such as the detected
>    host OpRegion version and address, the values for rvda, rvds,
>    and the guest OpRegion address when the guest_loglvl is set
>    to all/all.
> 
> Link: https://lore.kernel.org/kvm/[email protected]/
> Link: https://lore.kernel.org/kvm/[email protected]/
> Signed-off-by: Chuck Zmudzinski <[email protected]>
> ---
> Later versions of this patch will provide a link to the compatible patch
> for extended VBT support in the device model which will be posted to
> the qemu-devel and xen-devel mailing lists and Cc'd to the appropriate
> maintainers and reviewers soon.

I forgot to mention that there is an undocumented setting that works in
the xl.cfg(5) domain configuration file, firmware_override, that makes it
possible to use a patched version of hvmloader alongside an installation
of unpatched upstream Xen or a version of Xen packaged by a distro. So
one can download the source for one's installed version of Xen, apply this
patch and build just hvmloader and then install the patched version of
hvmloader with a different filename, such as hvmloader-igd-testing, into
the same directory where hvmloader is installed (usually something like
/usr/libexec/xen/boot) and then one can configure a guest to use the patched
version of hvmloader with one's installed version of Xen by adding a line
like this to the domain xl.cfg file:

firmware_override = 'hvmloader-igd-testing'

> 
> The compatible patch for the device model is part of a larger patchset
> that fixes many of the problems that currently affect the feature of
> Intel IGD passthrough to Xen HVM guests. This patch should be considered
> as a companion patch to that patchset for the device model. Do not try
> to test this patch with a real Intel IGD device without also applying
> the patchset for the device model because without those patches, the
> guest will most likely fail to start if an Intel IGD is passed through
> to the guest.
> 
> There are different requirements to support OpRegion version 2.0
> and OpRegion version 2.1+, with support for OpRegion 2 the more
> difficult case because it always requires modifications to the OpRegion
> for proper operation in the guest. For some details about OpRegion
> 2 and higher and the extended VBT, see the links in the commit message.
>