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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/20/2026 3:51 AM, Jan Beulich wrote:
> On 19.08.2026 19:13, Chuck Zmudzinski wrote:
>> On 8/19/2026 9:51 AM, Jan Beulich wrote:
>>> On 19.08.2026 14:36, Chuck Zmudzinski wrote:
>>>> On 8/19/2026 8:16 AM, Chuck Zmudzinski wrote:
>>>>> Yes, I agree that v3 of the patch to hvmloader should presume that the DM 
>>>>> can get
>>>>> a copy of the OpRegion and read its contents so most of this can be done 
>>>>> in the
>>>>> DM instead of in hvmloader. So from hvmloader's perspective, the patch 
>>>>> will be more
>>>>> about avoiding the layering violation than anything else.
>>>>
>>>> However, there is one advantage, from the viewpoint of the Xen 
>>>> virtualization platform
>>>> as a whole, to do the patching of the OpRegion in hvmloader instead of in 
>>>> the DM.
>>>>
>>>> If we patch the OpRegion in hvmloader as v2 of this patch does, we provide 
>>>> a common
>>>> solution for extended VBT support for Intel IGD devices that would be 
>>>> compatible with
>>>> all DM implementations, not just with Qemu. So why not do the patching of 
>>>> the OpRegion
>>>> in hvmloader?
>>>
>>> As indicated before: If the OpRegion holds data that is needed to drive the
>>> device, and if the OpRegion is exposed writable to guests, then guest can
>>> screw up that data such that subsequent guests won't work anymore. Hence
>>> exposing to guests (which includes hvmloader) needs to be stopped, or at
>>> least be limited to r/o. That, in fact, includes exposing to any privilege-
>>> restricted DM as well.
>>>
>>> Exposing r/o may be entirely okay (i.e. may not be a layering violation),
>>> depending how exactly an OpRegion surfaces for a device (on the host). Aiui
>>> it's not addressed by any of the BARs, yet it looks like it needs similar
>>> treatment.
>> 
>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>> it functions more or less like a BAR region with the devices's ASLS register
>> at offset 0xfc in the PCI device config space of the device acting like the
>> BAR for that region.
> 
> That is, on real hardware a write to that register moves the OpRegion? That
> would need following by the DM then, i.e. the DM would need to indicate the
> original position in the register, and the guest (incl hvmloader) would
> then be free to relocate it.

Why would that "need following by the DM" when the register in the guest is
fully emulated, [1] which means that when the guest (incl hvmloader) writes to 
the
register, the register on the real hardware is not touched, nor is the OpRegion
in the host address space moved?

Here is how I understand how this works in the current implementation and how
this should be done:

Intel's spec (an old version of it that does not yet define the rvda and rvds
fields) is available online. [2] What that spec says (it is for skylake 
processors,
released c. 2015 IIRC) is that the ASLS register is a write once register. The
system firmware is to place the OpRegion into memory anywhere below the 4 GiB 
limit
(because it is a 32-bit register) and mark it as type ACPI NVS memory in the 
E820 map,
and write once to that register the location of the OpRegion in the address 
space.
The spec says that from then on it is read-only for the OS graphics driver to 
consume.

When the IGD is passed through to a Xen HVM guest in the current implementation,
all 32 bits of the ASLS register are emulated from the guest's point of view. 
That
is, when the guest (hvmloader or seabios/ovmf) writes to it, the register on the
host (i.e. the register on the real, physical hardware) is not touched at all, 
nor
is the OpRegion moved in the host address space. I am fairly certain this setup 
of
having the ASLS register emulated is not specific to Qemu but applies to all DMs
that are to interface with the current implementation in hvmloader, because in
hvmloader we have this comment in tools/firmware/hvmloader/pci.c:

                    /*
                     * Write the the OpRegion offset to give the opregion
                     * address to the device model. The device model will trap 
                     * and map the OpRegion at the give address.
                     */

What does it mean to say the device model will trap? I think it means the
device model is to emulate all 32 bits of the ASLS register which will leave
the position of the OpRegion in the host address space unchanged and the ASLS
register on the real hardware untouched.

So, hvmloader need not need know the position of the OpRegion in the host 
address
space since the DM maps the host OpRegion into the guest address space at the
location it is to be accessed at in the guest. That is what the current
implementation in hvmloader presumes the DM will do, as evidenced by the comment
from hvmloader code quoted above, and it is also exactly what Qemu currently 
does.
Indeed, it is clear that in the current implementation, the host OpRegion 
address
is not disclosed to the guest (hvmloader) and the guest is able to access the 
host
OpRegion without knowing the OpRegion address in the host. That is my 
understanding
of how the current implementation works.

Now, we are proposing that the DM should expose a copy of the OpRegion to the
guest instead of mapping the host OpRegion into the guest address space. Even 
with
such a change from the way it is done now, hvmloader still need not know where 
the
OpRegion is on the host as long as the DM remains responsible (as it is in the 
current
implementation) for making the copy of the OpRegion for the guest accessible to 
the
OpRegion at (or near, because currently the address hvmloader writes to the 
register
is just a hint because the DM adds the offset from the page boundary to the 
address
in the current implementation) the address hvmloader has requested.

I think there are multiple ways for the DM to do this. It could place the copy 
of the
OpRegion into the guest memory at or near the address hvmloader requested 
without
disclosing the address of the OpRegion on the host. It could place the copy of 
the
OpRegion into the DM domain's memory and grant the guest access to it using 
grant tables.
There are probably also other ways to do it. IIUC, if the DM uses grant tables, 
it
would not need to disclose the address of the OpRegion in the host address 
space to
hvmloader.

There are even more options to accomplish this. For example, in a previous 
comment
you suggested that perhaps the DM should place a copy of the OpRegion *before* 
the
guest (hvmloader) ever gains control. I noted that would require making the spec
for how hvmloader computes the position the OpRegion will be at in the guest 
address
space public, and in that case the DM would compute the correct guest address
for the guest and place the suitably patched copy of the OpRegion into guest 
memory
at the correct address for the guest and program the ASLS register with the 
correct
guest address.

In this case, the patch to hvmloader would add a read of the ASLS register which
will allow hvmloader to determine, for example, if more space is needed in the 
E820
map to accommodate an extended VBT and adjust the E820 map appropriately, and 
also
in that case the device model would ignore any write that hvmloader currently 
does
to that register because in this case, the DM has already programmed the 
register
with the correct address.

So with all the different options about how to do this, my head is spinning and
since with your comments you are confusing me about what approach you think is 
best,
I cannot at the present time write v3 of this patch. What I need is for you or 
one
of the other maintainers of hvmloader to *make a decision* about how support for
extended VBT is to be added to the Xen platform. I think I have given you and 
the
other maintainers enough information to make a decision about how best to add 
support
for the extended VBT to the Xen platform. I understand it may take some time for
you to process all this information and make the decision, but at the present 
time
we seem to just be going around in circles discussing this, which is not really 
the
best use of either your time or my time.

Chuck

[1] The specification for how PCI config space registers are programmed for 
emulation
    vs. passthrough, please refer to the official PCI specification.
[2] 
https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html