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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/19/2026 11:47 AM, 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. 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.

As I noted earlier, it think it would be advantageous for the Xen platform as 
whole
for the patching to be done in hvmloader. That way, support for extended VBT is
automatically added for all implementations of the DM, not just for Qemu. But 
the
downside is that for hvmloader to do the patching, it needs to know the host 
OpRegion
address, which one could argue it should not need to know. This is the only 
reason I
can think of to do the patching of the OpRegion in the DM instead of in 
hvmloader: to
avoid disclosing the host OpRegion address to the guest.

But we trust hvmloader, don't we, to not abuse this knowledge of the host's 
OpRegion
address? The point is, hvmloader will discard the host OpRegion address and not
disclose it to guest firmware (ovmf/seabios) nor to the bootloader or guest OS, 
so
I think the advantage of adding support for extended VBT to all DMs that rely on
hvmloader outweighs the risk of disclosing the host OpRegion to the guest 
(hvmloader,
which, for security reasons, should not disclose it to ovmf or seabios).

Chuck