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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.08.2026 04:22, 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:
>>>>>>> +    printf("VBT size: 0x%x\n", rvds);
>>>>>>> +
>>>>>>> +    if ( !rvds || !rvda_host ) {
>>>>>>> +        printf("guest OpRegion address: 0x%x\n", igd_guest_opregion);
>>>>>>> +        rvda_host = 0;
>>>>>>> +    }
>>>>>>> +    /*
>>>>>>> +     * Write rvda_host as 2 successive 32-bit values
>>>>>>> +     * to communicate location of the VBT to the device
>>>>>>> +     * model. If rvda_host is not 0, The device model
>>>>>>> +     * unmaps the OpRegion and eventually maps the VBT
>>>>>>> +     * after we also write the guest address where the
>>>>>>> +     * VBT will be mapped.
>>>>>>> +     *
>>>>>>> +     * If we send rvda_host = 0 to the device model, it
>>>>>>> +     * will assume we do not need OpRegion 2 support and
>>>>>>> +     * it will not unmap the OpRegion.
>>>>>>> +     */
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)(rvda_host & 0xfffffffful));
>>>>>>> +    unsigned long rvda_host_upper_32 = (uint64_t)rvda_host >> 32;
>>>>>>> +    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
>>>>>>> +               (uint32_t)rvda_host_upper_32);
>>>>>>
>>>>>> Why would you need to communicate a host property to the DM?
>>>>>
>>>>> The DM cannot access the host rvda value because it is only accessible
>>>>> from the host kernel, and the DM is only a user-space process on the host.
>>>>
>>>> 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.
> 
> This is what I don't understand about your objection to how both the current
> implementation and my proposed changes makes the host OpRegion accessible to
> the guest. What do you mean when you say any MMIO and I/O ports assigned to
> a guest are also assigned to its DM? What does it mean to assign an MMIO
> region to a DM? Is it the DM you mean or the DM domain, which need not be
> dom0 if we are running the device model in an unprivileged domain.

The DM domain is what I meant. I thought that was clear / unambiguous here,
but apparently it wasn't: Sorry. Beyond that I hope that my reply to your
earlier mail provides sufficient further context.

> I also
> am presuming you know that dom0 for Intel IGD passthrough is a PV dom0,
> not a PVH dom0. I have never tried Intel IGD passthrough with a PVH dom0,
> because as far as I can tell vt-d is not supported with PVH dom0.

I don't see why PVH Dom0 would start to matter here all of the sudden.

> Take a look at this code from our current implementation in qemu-xen. This
> is from the current master branch of qemu-xen on xenbits.xen.org, the
> hw/xen/xen_pt_graphics.c file, the igd_write_opregion function:
> 
> --- snip ---
> 
> #define XEN_PCI_INTEL_OPREGION_PAGES 0x3
> #define XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED 0x1
> void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val)
> {
>     int ret;
> 
>     if (igd_guest_opregion) {
>         XEN_PT_LOG(&s->dev, "opregion register already been set, ignoring 
> %x\n",
>                    val);
>         return;
>     }
> 
>     /* We just work with LE. */
>     xen_host_pci_get_block(&s->real_device, XEN_PCI_INTEL_OPREGION,
>             (uint8_t *)&igd_host_opregion, 4);
>     igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK)
>                             | (igd_host_opregion & 
> XEN_PCI_INTEL_OPREGION_MASK);
> 
>     ret = xc_domain_iomem_permission(xen_xc, xen_domid,
>             (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>             XEN_PCI_INTEL_OPREGION_PAGES,
>             XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED);

So this is where permissions are granted (wrongly imo, as I think permissions
for MMIO or I/O ports should only ever be granted by the control domain).

>     if (ret) {
>         XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:"
>                     " 0x%lx.\n", ret,
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)),
>         igd_guest_opregion = 0;
>         return;
>     }
> 
>     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);

This is where, as said in the earlier reply, a mapping is installed in the
guest's P2M.

>     if (ret) {
>         XEN_PT_ERR(&s->dev, "[%d]:Can't map IGD host opregion:0x%lx to"
>                     " guest opregion:0x%lx.\n", ret,
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>                     (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
>         igd_guest_opregion = 0;
>         return;
>     }
> 
>     XEN_PT_LOG(&s->dev, "Map OpRegion: 0x%lx -> 0x%lx\n",
>                     (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT),
>                     (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT));
> }
> 
> [...]
> 
> Do you understand now?

Yes, and as said in the earlier reply: This demonstrates that the DM does
have permission to access the pages in question.

Jan