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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/18/2026 1:15 PM, Chuck Zmudzinski wrote:
> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>> On 17.08.2026 18:04, Chuck Zmudzinski wrote:
>>>>>> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>>>>>>> On 14.08.2026 17:23, Chuck Zmudzinski wrote:
>>>>>>>> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>>>>>>>>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>>>>>>>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>>>>>>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>>>>>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>>>>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>>>>>>>>> -- snip --
>>>>>>>>>>>>>> +    /*
>>>>>>>>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>>>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>>>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>>>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>>>>>>>>> +     * after we also write the guest address where the
>>>>>>>>>>>>>> +     * VBT will be mapped.
>>>>>>>>>>>>>> +     *
>>>>>>>>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>>>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>>>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>>>>>>>>> +     */
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>>>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 
>>>>>>>>>>>>>> 32;
>>>>>>>>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>>>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why would you need to communicate a host property to the DM?
>>>>>>>>>>>>
>>>>>>>>>>>> The DM cannot access the host rvda value because it is only 
>>>>>>>>>>>> accessible
>>>>>>>>>>>> from the host kernel, and the DM is only a user-space process on 
>>>>>>>>>>>> the host.
>>>>>>>>>>>
>>>>>>>>>>> I don't follow this: Anything the guest can access should also be 
>>>>>>>>>>> accessible
>>>>>>>>>>> by its DM.
>>>>>>>>>>
>>>>>>>>>> I think the host OpRegion is not currently accessible by the DM.
>>>>>>>>>
>>>>>>>>> Can you explain to me how the region becomes accessible to the guest?
>>>>>>>>> That would then (hopefully) help me understand why the DM would not 
>>>>>>>>> have
>>>>>>>>> access. Fundamentally any MMIO and any I/O ports that are assigned to 
>>>>>>>>> a
>>>>>>>>> guest are also assigned to its DM.
>>>>>>>>
>>>>>>>> Currently, in the device model (Qemu) we have:
>>>>>>>>
>>>>>>>>     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,
>>>>>>>>             DPCI_ADD_MAPPING);
>>>>>>>>
>>>>>>>> That statement is in the igd_write_opregion(...) function in the
>>>>>>>> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.
>>>>>>>>
>>>>>>>> If I understand our current implementation correctly, this statement
>>>>>>>> is what gives the guest access to the host OpRegion (3 pages as defined
>>>>>>>> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with 
>>>>>>>> IGD_OPREGION_PAGES
>>>>>>>> in hvmloader code).
>>>>>>>
>>>>>>> No, it introduces mappings of those pages into the guest's P2M.
>>>>>>>
>>>>>>>> I don't think this statement makes the host OpRegion
>>>>>>>> accessible to the device model, though, so I think, if I understand 
>>>>>>>> your
>>>>>>>> comment in an earlier about my patch resulting in what you called a 
>>>>>>>> "layering
>>>>>>>> violation" correctly, that our current implementation is also guilty 
>>>>>>>> of this
>>>>>>>> same kind of "layering violation."
>>>>>>>
>>>>>>> That code, if it can be successfully executed, indeed doesn't grant any
>>>>>>> permissions (to the DM or the guest). Instead it proves that the DM has 
>>>>>>> the
>>>>>>> needed permissions to access the pages itself.
>>>>>>
>>>>>> So, are you saying it should be possible, without any patches to either 
>>>>>> Xen or
>>>>>> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
>>>>>>
>>>>>> I think I could implement what you proposed in an earlier message and do
>>>>>> all (or most) of this in the DM instead of here in hvmloader:
>>>>>>
>>>>>>> The more correct thing to do might be for the DM to
>>>>>>> put in place a copy before the guest (i.e. hvmloader) even gains 
>>>>>>> control.
>>>>>>> (How in turn the DM would learn of the contents of the opregion is a
>>>>>>> separate question then.)
>>>>>>
>>>>>> Actually, when I was developing this patch, I tried first to do it that
>>>>>> way, but the problem was, I could not find a way to get a pointer to the
>>>>>> host OpRegion in Qemu.
>>>>>>
>>>>>> So, how can I get a pointer to the host OpRegion in Qemu?
>>>>>
>>>>> You don't ask me this question, do you?
>>>> 
>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>> again.
>>> 
>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>> qemu person, and I never have been. I can't really help much there.
>>> 
>>>> All I can say is that surely qemu
>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>> (independently) there and here there's the issue of how to accomplish
>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>> 
>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>> can access the MSI-X table of some device, that does not prove that
>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>> still stands: I still don't see proof that it is possible for Qemu
>>>> to get a pointer to the host OpRegion without any patches to the current
>>>> implementations of Xen and the Linux kernel.
>>> 
>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>> could come up with, as that's one tiny area of qemu that I know at least
>>> a little.
>>> 
>>> From a Xen perspective, this analogy should be sufficient: All you need
>>> from Xen is for it to permit to establish mappings of the underlying page.
>>> As I've pointed out when commenting on a code fragment you presented, the
>>> DM (domain) looks to have permission. Everything else is a matter of
>>> establishing such a mapping. There the MSI-X table code may also guide
>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>> imo a layering violation.)
>> 
>> I agree that accessing the host /dev/mem directly is cringy. I would not
>> really want to do it that way for the host OpRegion.
> 
> I looked at the current mainline Linux kernel code about access to memory 
> using
> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
> ordinary system RAM but allows access to what the kernel developers call
> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
> in the Linux source code:
> 
>>  * On x86, access has to be given to the first megabyte of RAM because that
>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>  * and similar apps. Since they map the entire memory range, the whole range
>>  * must be allowed (for mapping), but any areas that would otherwise be
>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>  * PCI mmio resources as well as potential bios/acpi data regions.
> 
> So I think things like the MSI-X table and the OpRegion would qualify for
> /dev/mem access even with CONFIG_STRICT_DEVMEM set, so after seeing this
> I expect I could get a pointer to the OpRegion running in Qemu using
> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
> But as I said earlier, I agree that /dev/mem and mmap does not feel like
> the right way to do it.

Moreover, I tried accessing the OpRegion using /dev/mem and mmap using a
little C program, dumpmem, [1] I found but it does not work in either dom0
or in the guest when IGD is passed through to the guest: mmap returns
MAP_FAILED and reports the EPERM error: Operation not permitted. So it looks
like Qemu cannot access the OpRegion using mmap and /dev/mem with current
Linux kernels. So I am still skeptical that with current Linux kernel
implementation and its hardening mechanisms such as CONFIG_STRICT_DEVMEM, it
is not possible for Qemu to directly access the OpRegion without also adding a
patch to either Linux or Xen to provide access of OpRegion contents to Qemu. 

But the good news is I did find a way to dump the OpRegion to a file from
either dom0 or the guest when passed through, but in dom0 it works only before
xl makes the device assignable for passthrough and bound to xen-pciback, so that
is not so helpful since we need Qemu to access it when the IGD is assigned to
its guest and bound to the xen-pciback kernel driver.

Here is how I accessed the OpRegion from dom0 userland before xl assigns it
for Xen PCI passthrough:

Linux debugfs mentioned in the man page for IGT GPU tools [2] exposes the 
OpRegion:

https://manpages.debian.org/trixie/intel-gpu-tools/intel_vbt_decode.1.en.html

Here is how to dump the OpRegion contents to a file in the home directory:

user@dom0:~$ sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_opregion > 
~/i915_opregion
user@dom0:~$ ls -l ~/i915_opregion
-rw-r--r--. 1 chuckz chuckz 8192 Aug 18 22:41 /home/chuckz/i915_opregion
user@dom0:~$

There it is, the 8k OpRegion dumped to a file.

This also works for the VBT:

user@dom0:~$ sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_vbt > ~/i915_vbt
user@dom0:~$ ls -l ~/i915_vbt
-rw-r--r--. 1 chuckz chuckz 8704 Aug 18 22:48 /home/chuckz/i915_vbt
user@dom0:~$

So now, with a copy of both the OpRegion and VBT, I can write and test
patches to hvmloader and Qemu using your approach of exposing a copy
and never mapping the host OpRegion to the guest and in that way avoid the
layering violation. The TODO is to find a way for Qemu to get a copy of
the OpRegion on the fly instead of only after the administrator places
a copy of it in the dom0 filesystem where Qemu can access it.

I think one way to make the OpRegion directly accessible to Qemu instead
of being accessible only after dumping it to a file and placing the dumped
file where Qemu can access it would be to provide a xen-intelgpuback kernel
driver whose job would be to make the OpRegion and VBT accessible to Qemu
when the device is assigned to a Xen HVM guest.

Chuck

[1] https://github.com/tchebb/memdump
[2] https://drm.pages.freedesktop.org/igt-gpu-tools/