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

[Chuck Zmudzinski <brchuckz@xxxxxxx>]

On 8/19/2026 3:30 AM, Jan Beulich wrote:
> On 18.08.2026 19:15, Chuck Zmudzinski wrote:
>> On 8/18/2026 8:29 AM, Chuck Zmudzinski wrote:
>>> On 8/18/2026 8:18 AM, Jan Beulich wrote:
>>>> On 18.08.2026 13:52, Chuck Zmudzinski wrote:
>>>>> On 8/18/2026 3:17 AM, Jan Beulich wrote:
>>>>>> On 17.08.2026 18:04, 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?
>>>>>>
>>>>>> You don't ask me this question, do you?
>>>>>
>>>>> Are you offended I asked this question? If so, I am sorry. You make me
>>>>> afraid to ask it again so I will not do so unless you permit to do so
>>>>> again.
>>>>
>>>> "Offended" is the wrong word; "very puzzled" may better get it. I'm not a
>>>> qemu person, and I never have been. I can't really help much there.
>>>>
>>>>> All I can say is that surely qemu
>>>>>> has an existing way to map (host) physical memory; see e.g. how
>>>>>> xen_pt_msix_init() (imo bogusly) maps the physical MSI-X table of a
>>>>>> device. "Bogusly" there because that's another layering violation. Plus
>>>>>> (independently) there and here there's the issue of how to accomplish
>>>>>> things when not running in Dom0, or when running de-privileged in Dom0.
>>>>>
>>>>> Well, that only proves Qemu *might* be able to access the MSI-X table of
>>>>> a device, that is, if the calls to open /dev/mem and mmap it succeed.
>>>>> Why is the MSI-X table all of the sudden relevant? Even if Qemu
>>>>> can access the MSI-X table of some device, that does not prove that
>>>>> Qemu can access the host OpRegion of an Intel IGD. So I think my point
>>>>> still stands: I still don't see proof that it is possible for Qemu
>>>>> to get a pointer to the host OpRegion without any patches to the current
>>>>> implementations of Xen and the Linux kernel.
>>>>
>>>> The MSI-X table (and it being accessible to qemu) is the best analogy I
>>>> could come up with, as that's one tiny area of qemu that I know at least
>>>> a little.
>>>>
>>>> From a Xen perspective, this analogy should be sufficient: All you need
>>>> from Xen is for it to permit to establish mappings of the underlying page.
>>>> As I've pointed out when commenting on a code fragment you presented, the
>>>> DM (domain) looks to have permission. Everything else is a matter of
>>>> establishing such a mapping. There the MSI-X table code may also guide
>>>> you. (Sadly it may also misguide you, since (a) I don't know whether it's
>>>> appropriate to do things this way in qemu, and since (b) it is, as said,
>>>> imo a layering violation.)
>>>
>>> I agree that accessing the host /dev/mem directly is cringy. I would not
>>> really want to do it that way for the host OpRegion.
>> 
>> I looked at the current mainline Linux kernel code about access to memory 
>> using
>> /dev/mem and modern distros set CONFIG_STRICT_DEVMEM which forbids access to
>> ordinary system RAM but allows access to what the kernel developers call
>> non-kernel memory. Here is a quote from a comment in arch/x86/mm/init.c file
>> in the Linux source code:
>> 
>>>  * On x86, access has to be given to the first megabyte of RAM because that
>>>  * area traditionally contains BIOS code and data regions used by X, dosemu,
>>>  * and similar apps. Since they map the entire memory range, the whole range
>>>  * must be allowed (for mapping), but any areas that would otherwise be
>>>  * disallowed are flagged as being "zero filled" instead of rejected.
>>>  * Access has to be given to non-kernel-ram areas as well, these contain the
>>>  * PCI mmio resources as well as potential bios/acpi data regions.
>> 
>> So I think things like the MSI-X table and the OpRegion would qualify for
>> /dev/men access even with CONFIG_STRICT_DEVMEM set, so after seeing this
>> I expect I could get a pointer to the OpRegion running in Qemu using
>> /dev/mem and mmap, as long as it is running in dom0 with root privileges.
>> But as I said earlier, I agree that /dev/mem and mmap does not feel like
>> the right way to do it.
>> 
>> So I would like to come back to something else you said in an earlier 
>> message:
>> 
>>> (How in turn the DM would learn of the contents of the opregion is a 
>>> separate
>>>  question then.)
>> 
>> Let me phrase the question like this: How could the DM gain access to the 
>> contents
>> of the OpRegion, and for that matter, also the contents of the MSI-X table, 
>> without
>> also committing a layering violation?
> 
> As said previously, I'm not a qemu person at all. Yet it's entirely a qemu
> question you raise. From Xen's perspective, as also said previously, the
> one prereq is there - the DM domain is permitted to access the page(s) in
> question.

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.

Chuck

> 
> Jan