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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/20/2026 9:03 AM, Chuck Zmudzinski wrote:
> 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).

Ah, I see this message is the one you sent me earlier today about this patch 
and now
the list archive has caught up so for those who might be reading this thread 
here
is the link:

https://lore.kernel.org/xen-devel/92022f85-9a53-4db8-b489-fc91c86b413c@xxxxxxxx/

Well, I did try to answer this question here:

https://lore.kernel.org/xen-devel/fa497825-c8f0-4caf-94f5-b37108e31952@xxxxxxx/

My answer is based on the fact, as far as I understand it, the ASLS register
on the real hardware is not touched when the guest writes to it because in our
case the register is fully emulated and the guest can only access and write to 
or
read from the emulated virtual register, not the real register on the hardware.

Also, we have this code in Qemu (hw/xen/xen_pt_config_init.c):

static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = {
    /* Intel IGFX OpRegion reg */
    {
        .offset     = 0x0,
        .size       = 4,
        .init_val   = 0,
        .emu_mask   = 0xFFFFFFFF,
        .u.dw.read   = xen_pt_intel_opregion_read,
        .u.dw.write  = xen_pt_intel_opregion_write,
    },

Do you see that emu_mask setting of 0xFFFFFFFF? As I understand it, that means
that all 32 bits of the register are emulated, and none of the bits are passed
through to the real device.

Also, I can quote from the (admittedly outdated) spec for the OpRegion that is
available online [1] which says this about the ASLS register of the IGD PCI 
device
in section 5.1.2 of that document:

> This register is a software scratch register and is not used by hardware
> other than to hold the state software has set.

I think this means that even if the real hardware register on the device was 
exposed
to the guest and the guest wrote a different address to the register, it would
*not* "move" the host OpRegion anywhere because, as the spec says, the register 
is
not used by hardware but by software (the system BIOS software) to let the 
graphics
driver know where it can find the OpRegion. But the guest *cannot* access the 
real
ASLS register on the device in our implementation nor in my proposed 
implementation
in v2 of this patch or in any of the other ways to solve this problem that we
have discussed in this thread.

So I don't understand how the question you raise poses a serious problem.

But if you are not an expert on the PCI specification and how the PCI config 
space
registers can be programmed with emulated bits and passthrough bits, and if you
don't trust my understanding of it either, then I think we need to wait for
experts on the PCI specification to weigh in and answer your question before we
can move forward.

Chuck

[1] 
https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/opregion-specification.html

    To actually see the spec, click on the "OpRegion Specification" link in the 
page
    shown above and download the pdf file that link points to. It is still 
live, I
    checked it today.