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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.08.2026 13:47, Chuck Zmudzinski wrote:
> On 8/20/2026 3:51 AM, Jan Beulich wrote:
>> On 19.08.2026 19:13, 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.
>>>
>>> Yes, the OpRegion is not one of the BARs as specified by the PCI specs, but
>>> it functions more or less like a BAR region with the devices's ASLS register
>>> at offset 0xfc in the PCI device config space of the device acting like the
>>> BAR for that region.
>>
>> That is, on real hardware a write to that register moves the OpRegion? That
>> would need following by the DM then, i.e. the DM would need to indicate the
>> original position in the register, and the guest (incl hvmloader) would
>> then be free to relocate it.
> 
> Why would that "need following by the DM" when the register in the guest is
> fully emulated, [1] which means that when the guest (incl hvmloader) writes 
> to the
> register, the register on the real hardware is not touched, nor is the 
> OpRegion
> in the host address space moved?

You said it's BAR-like. If the guest writes to a BAR, the referenced MMIO
region moves accordingly.

> Here is how I understand how this works in the current implementation and how
> this should be done:

I'm sorry, but this is getting out of hand, at least as far as I'm concerned.
I've been trying to help, but even just reading your replies has already been
taking way more time than I would have wanted to spend here.

Jan