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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

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

I apologize for the tone of my last message which I wrote before I saw this 
message.
(Unfortunately some of your messages are going to the spam folder, I will try 
to fix
that, but it seems aol.com's spam filters are not all that smart)

I was really hoping you would answer this question and I appreciate that you are
able to give me a tentative answer favoring option 1. 

To follow up on what I did say in the last message, I think we have exhausted 
what
you and I can agree on and now would be a good time to pause this discussion and
I will write a new version of the Qemu patches and v3 of this patch assuming 
what
I said in option 1, and hopefully the Qemu maintainers will help us out by 
replying
to a version of the Qemu patches that does the patching of the OpRegion in Qemu 
instead
of in hvmloader. So far none of the Qemu maintainers have replied to my Qemu 
patches,
unfortunately, but ultimately, we at some point will need their input to decide 
how
best to do this, so until they respond to the Qemu patchsets I posted, I think 
we
just have to wait now until they weigh in with their thoughts and opinions.

Chuck