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

[Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>]

On 6/17/22 9:46 AM, Anthony PERARD wrote:
> On Thu, Mar 31, 2022 at 03:44:33PM -0400, Chuck Zmudzinski wrote:
> > On 3/31/22 10:19 AM, Jason Andryuk wrote:
> > > On Thu, Mar 31, 2022 at 10:05 AM Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx> wrote:
> > > > 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.
> > > [...]
> > I know of another reason to check the Qemu upstream version,
> > and that is dealing with deprecated / removed device model
> > options that xl.cfg still uses. I looked at that a few years ago
> > with regard to the deprecated 'usbdevice tablet' Qemu option,
> > but I did not see anything in libxl to distinguish Qemu versions
> > except for upstream vs. traditional. AFAICT, detecting traditional
> > vs. upstream Qemu depends solely on the device_model_version
> > xl.cfg setting. So it might be useful for libxl to add the capability
> > to detect the upstream Qemu version or at least create an xl.cfg
> > setting to inform libxl about the Qemu version.
> Hi,
>
> There's already some code to deal with QEMU's version (QEMU = upstream
> Qemu) in libxl, but this code is dealing with an already running QEMU.
> When libxl interact with QEMU through QMP, to setup some more devices,
> QEMU also advertise it's version, which we can use on follow up qmp
> commands.
>
> I think adding passthrough pci devices is all done via QMP, so we can
> potentially move an hypercall from QEMU to libxl, and tell libxl that
> depending on which version of QEMU is talking to, it needs or not do the
> hypercall. Also, we could probably add a parameter so that QEMU know if
> it have to do the hypercall or not, and thus newer version of QEMU could
> also deal with older version of libxl.
>
> (There's maybe some example like that in both QEMU and libxl, when doing
> live migration, dm_state_save_to_fdset() in libxl as a pointer)
>
> Cheers,
Hi Anthony,

Thanks for this information, it is useful because I plan to work on
improved Xen / Qemu interactions to better support features
such as running the device model in a stub domain, in which case
it is probably better to do some hypercalls in libxl or maybe in
hvmloader that are currently done in Qemu.

I also would like to see Xen HVM using Q35 instead of i440fx
emulation which also requires improved Xen / Qemu interactions.
I know of the patch set for Q35 emulation that was proposed back
in 2018, but I have not tried anything like that yet. That looks like
a complex problem. Has there been any more recent work in that
area? I couldn't find much recent work on that by searching the
Internet. I have quite a bit to learn before I can make contributions
to support Q35 as a replacement for i440fx, but I plan to slowly
work on it. Any suggestions anyone has are welcome.

Best Regards,

Chuck