Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx> wrote:
>
> On 3/31/2022 8:29 AM, Jason Andryuk wrote:
> > On Wed, Mar 30, 2022 at 11:54 PM Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx> 
> > wrote:
> >> On 3/30/22 1:27 PM, Andrew Cooper wrote:
> >>>
> >>> This has been discussed before, but noone's done anything about it.
> >>> It's a massive layering violation for QEMU to issue
> >>> xc_domain_iomem_permission()/etc hypercalls.
> >>>
> >>> It should be the toolstack, and only the toolstack, which makes
> >>> permissions hypercalls, which in turn will fix a slew of "QEMU doesn't
> >>> work when it doesn't have dom0 superpowers" bugs with stubdomains.
> >> How much say does the Xen project have over the code
> >> in Qemu under hw/xen? I would not be against having libxl
> >> do the permissions hypercalls in this case instead of Qemu
> >> doing it. My test with Qemu traditional and this patch proves
> >> the permission can be granted by libxl instead of the device
> >> model.
> > Qubes patches libxl and QEMU, and they move the hypercalls to the
> > toolstack.  They are using linux stubdoms, and I think it works for
> > them.
>
> That still doesn't answer my question - will the Qemu upstream
> accept the patches that move the hypercalls to the toolstack? If
> not, we have to live with what we have now, which is that the
> hypercalls are done in Qemu.

Xen-associated people maintain hw/xen code in QEMU, so yes it could be accepted.

Maybe it would need to be backwards compatible to have libxl check the
QEMU version to decide who makes the hypercall?  Unless it is broken
today, in which case just make it work.

Regards,
Jason