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

On 8/14/2026 11:23 AM, Chuck Zmudzinski wrote:
> On 8/14/2026 9:46 AM, Jan Beulich wrote:
>> On 14.08.2026 15:18, Chuck Zmudzinski wrote:
>>> On 8/14/2026 3:35 AM, Jan Beulich wrote:
>>>> On 14.08.2026 02:45, Chuck Zmudzinski wrote:
>>>>> On 8/13/2026 6:35 AM, Jan Beulich wrote:
>>>>>> On 02.08.2026 07:08, Chuck Zmudzinski wrote:
>>>>>>> -- snip --
>>>>
>>>> I don't follow this: Anything the guest can access should also be accessible
>>>> by its DM.
>>> 
>>> I think the host OpRegion is not currently accessible by the DM.
>> 
>> Can you explain to me how the region becomes accessible to the guest?
>> That would then (hopefully) help me understand why the DM would not have
>> access. Fundamentally any MMIO and any I/O ports that are assigned to a
>> guest are also assigned to its DM.
> 
> Currently, in the device model (Qemu) we have:
> 
>     ret = xc_domain_memory_mapping(xen_xc, xen_domid,
>             (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT),
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             DPCI_ADD_MAPPING);
> 
> That statement is in the igd_write_opregion(...) function in the
> hw/xen/xen_pt_graphics.c file of the upstream Qemu source.

I forgot to mention: In our current implementation, this statement is
executed in the DM when hvmloader executes this statement, currently in
hvmloader/pci:

                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
                               igd_opregion_pgbase << PAGE_SHIFT);



> 
> If I understand our current implementation correctly, this statement
> is what gives the guest access to the host OpRegion (3 pages as defined
> by XEN_PCI_INTEL_OPREGION_PAGES, and in agreement with IGD_OPREGION_PAGES
> in hvmloader code). I don't think this statement makes the host OpRegion
> accessible to the device model, though, so I think, if I understand your
> comment in an earlier about my patch resulting in what you called a "layering
> violation" correctly, that our current implementation is also guilty of this
> same kind of "layering violation."
> 
> So, how do you suggest we fix that?
> 
...