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

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

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.

Regards,

Chuck