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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.08.2026 19:49, Chuck Zmudzinski wrote:
> 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?

No, we cannot (fully) trust hvmloader.

Jan

> 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