[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Chuck Zmudzinski <brchuckz@xxxxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Fri, 17 Jun 2022 14:46:08 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Jason Andryuk <jandryuk@xxxxxxxxx>, Andrew Cooper <amc96@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "Juergen Gross" <jgross@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Fri, 17 Jun 2022 13:46:54 +0000
  • Ironport-data: A9a23:6GIky6sOwfAPxp46tJODr2rUkufnVH1eMUV32f8akzHdYApBsoF/q tZmKWmEPaqDZTfxf9Eka9i38htQvZHQn9RqTVA5pXo8Hn4U+JbJXdiXEBz9bniYRiHhoOOLz Cm8hv3odp1coqr0/0/1WlTZhSAgk/nOHNIQMcacUsxLbVYMpBwJ1FQywYbVvqYy2YLjW13U5 4uuyyHiEATNNwBcYzp8B52r8HuDjNyq0N/PlgVjDRzjlAa2e0g9VPrzF4noR5fLatA88tqBb /TC1NmEElbxpH/BPD8HfoHTKSXmSpaKVeSHZ+E/t6KK2nCurQRquko32WZ1he66RFxlkvgoo Oihu6BcRi8zPPbvmNRCciNEFgpaIPxtpZLJYkqg5Jn7I03uKxMAwt1rBUAye4YZ5vx2ESdF8 vlwxDIlN07ZwbjsmfTiF7cq1p9LwMrDZevzvllpyy3ZCvA3B4jOWazQ6fdT3Ssqh9AIFvHbD yYcQWUxME2aO0MTUrsRII06nqSN2WnjSSYClEK3+7c9ykaN9xMkhdABN/KKI4fXFK25hH2wu Wbu72n/RBYAO7S3yzWf9Wm3rvTShi69U4UXfJW6/PN3hFyYxkQIFQYbE1C8pJGRmkO4Ht5SN UEQ0i4vtrQpslymSMHnWB+1q2LCuQQTM/JaCeY69QqO2ILS7hqCDWEcQ3hHZcBOnM0/QzAwx 0KKt9zsDD1r9raSTBq1/7Kf/G2aIjIeIykEaDNscOcey4C9+sdp1EuJF4s9Vv7u5jHoJd3u6 yqI9ws+t+oyt9IO/IGmrHuarjzvlIecG2bZ+T7rsnKZAhJRPdD4OtDzsQKDsJ6sP67CEADf4 SFsd9y2qblXUMrTzHHlrPAlRunB2hqTDNHLbbeD9bEF/i/lxXOsdJs4DNpWdBYwaZZsldMEj SbuVeJtCHx7ZiLCgVdfOd7ZNijQ8YDuFM7+StffZcdUb556eWevpX8zOBLIgzywyBFxy8nT3 Kt3lu79ZUv29Iw9lGbmLwvj+eRDKt8CKZP7GsmgkkXPPUu2b3+JU7YVWGazghQCxPrc+m39q o8HX+PTkkk3eLCuM0H/rN9IRXhXfCdTOHwDg5EOHsaZPBFcEX0sY9eIh+tJl3pNxP8OyI8lP xiVBydl9bYIrSeXdlnSNik7MumHsFQWhStTABHA9G2AgxALCbtDJo9DH3frVdHLLNBe8MM=
  • Ironport-hdrordr: A9a23:23/5pKAARxqNpT3lHemu55DYdb4zR+YMi2TC1yhKKCC9Vvbo8P xG/c5rsSMc5wx8ZJhNo7+90ey7MBXhHP1OkOws1NWZLWrbUQKTRekIh+bfKn/bak/DH4ZmpN 5dmsNFaOEYY2IVsfrH
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.
> > 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
> 
> 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,

-- 
Anthony PERARD



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.