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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

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. Earlier on we also talked about the region not necessarily being
> page-aligned. That poses, even with r/o exposure, the question of other
> data on the same (leading / trailing) pages. This may imply that the
> copying needs to be done strictly in Dom0, for both DM and guest to only
> ever act on copies (which may then as well be r/w).

Yes, I am thinking the DM should make a copy host OpRegion and never expose
the host OpRegion to the guest but only a copy of it.

The reason we need a patch like this is that with the introduction of the
rvda/rvds fields into the OpRegion, the OpRegion is not always 
position-independent
so its contents might be unsuitable in the guest address space, so in those 
cases
we need to patch the copy of the OpRegion that will be exposed to the guest.
If there is an extended VBT the DM will also get a copy of it, make a copy of
it, and expose it to the guest by appending it contiguous with the OpRegion.
Since in this scenario we are assuming the DM knows the contents of the 
OpRegion,
then it can find the host VBT and make a copy of it without needing hvmloader
to send the rvda and rvds values to it.

Then, the remaining question is which component (DM or hvmloader) will patch it
if it needs to be patched to make the guest's copy of it compatible with the 
guest
address space. It could be done in the DM only after hvmloader informs the DM
where in the guest it will be in the memory map unless we make the 
specifications
for how hvmloader determines where it will be in the guest address space public 
so
the DM can compute where the OpRegion will be in the guest address space. 
Currently,
the DM learns this from hvmloader when hvmloader writes the guest 
igd_opregion_phbase
value to the ASLS register of the device (in hmvlmoader code we currently name 
the
ASLS register for the OpRegion using the PCI_INTEL_OPREGION macro, which is 
defined to
be 0xfc). 

Chuck