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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/17/2026 12:04 PM, Chuck Zmudzinski wrote:
> On 8/17/2026 4:42 AM, Jan Beulich wrote:
>> On 14.08.2026 17:23, 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 --
>>>>>>>>> +    /*
>>>>>>>>> +     * 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.
>>> 
>>> 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.
>>> 
>>> 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).
>> 
>> No, it introduces mappings of those pages into the guest's P2M.
>> 
>>> 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."
>> 
>> That code, if it can be successfully executed, indeed doesn't grant any
>> permissions (to the DM or the guest). Instead it proves that the DM has the
>> needed permissions to access the pages itself.
> 
> So, are you saying it should be possible, without any patches to either Xen or
> the Linux kernel, for Qemu to get a pointer to the OpRegion? If so, how?
> 
> I think I could implement what you proposed in an earlier message and do
> all (or most) of this in the DM instead of here in hvmloader:
> 
>> The more correct thing to do might be for the DM to
>> put in place a copy before the guest (i.e. hvmloader) even gains control.
>> (How in turn the DM would learn of the contents of the opregion is a
>> separate question then.)
> 
> Actually, when I was developing this patch, I tried first to do it that
> way, but the problem was, I could not find a way to get a pointer to the
> host OpRegion in Qemu.
> 
> So, how can I get a pointer to the host OpRegion in Qemu?
> 

I also think that if we use a fully emulated copy of the OpRegion
instead of passing it through, we might not need to allocate space for
it in the RESERVED region and allocate it instead contiguous with the
rest of the NVS region. This means we might be able to avoid needing
to split the REVERSED region in hvmloader/e820.c which is currently
done like this:

    /*
     * If igd_opregion_pgbase we need to split the RESERVED region in two.
     */

    if ( igd_opregion_pgbase )
    {
        uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;

        e820[nr].addr = acpi_mem_end;
        e820[nr].size = igd_opregion_base - acpi_mem_end;
        e820[nr].type = E820_RESERVED;
        nr++;

        e820[nr].addr = igd_opregion_base;
        e820[nr].size = IGD_OPREGION_PAGES * PAGE_SIZE;
        e820[nr].type = E820_NVS;
        nr++;

        e820[nr].addr = igd_opregion_base + IGD_OPREGION_PAGES * PAGE_SIZE;
        e820[nr].size = (uint32_t)-e820[nr].addr;
        e820[nr].type = E820_RESERVED;
        nr++;
    }
    else
    {
        e820[nr].addr = acpi_mem_end;
        e820[nr].size = (uint32_t)-e820[nr].addr;
        e820[nr].type = E820_RESERVED;
        nr++;
    }

I am not sure this would work but I think the need to map the OpRegion
to the RESERVED region arises from the fact that currently it is passed
directly mapped from the host. I think I will try it out and see if that
would work.

>> This is what the handling of
>> XEN_DOMCTL_memory_mapping has in this regard:
>> 
>>         ret = -EPERM;
>>         if ( !iomem_access_permitted(current->domain, mfn, mfn_end) )
>>             /* Nothing. */;
>> 
>> Subsequently we check that the guest is also permitted access:
>> 
>>         else if ( iomem_access_permitted(d, mfn, mfn_end) )
> 
> 
> 
> 
> 
>> 
>> Jan
>