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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/20/2026 3:53 AM, Jan Beulich wrote:
> 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.

That is good to know.

Chuck