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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.08.2026 21:09, Chuck Zmudzinski wrote:
> On 8/19/2026 1:49 PM, 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.
> 
> Correction: Actually, with this new scenario, we need not disclose any 
> confidential
> host addresses to hvmloader if the DM removes such information from the copy 
> of
> the OpRegion that it exposes to hvmloader. Then, all hvmloader needs to know 
> to
> ensure the OpRegion is compatible with the guest's address space is the guest
> address of the OpRegion. It need not know either the host OpRegion address or 
> the
> host VBT address.
> 
> So the guidance I need from you to do v3 of the patch is simply to answer 
> these
> two questions.
> 
> 1. Should I write v3 of the patch not only assuming the DM will never expose 
> the
> host OpRegion to hvmloader, but also assuming that the DM is responsible for
> patching the OpRegion to ensure it is compatible with guest address space?
> 
> Or
> 
> 2. Should I write v3 of the patch assuming that hvmloader is responsible for
> patching the OpRegion so it is compatible with the guest address space?

My tentative response is to use option 1, not the least because a mid to long 
term
plan is to see about removing hvmloader altogether. However, a more firm 
response
here depends on an answer to the question raised in
<92022f85-9a53-4db8-b489-fc91c86b413c@xxxxxxxx> (sorry, the list archive hasn't
caught up yet).

Jan