All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony.perard@citrix.com>
To: Chuck Zmudzinski <brchuckz@netscape.net>
Cc: Jason Andryuk <jandryuk@gmail.com>,
	Andrew Cooper <amc96@srcf.net>,
	xen-devel <xen-devel@lists.xenproject.org>, Wei Liu <wl@xen.org>,
	"Juergen Gross" <jgross@suse.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion
Date: Fri, 17 Jun 2022 14:46:08 +0100	[thread overview]
Message-ID: <YqyFoPJ8Bv9EnO5N@perard.uk.xensource.com> (raw)
In-Reply-To: <ea5c1606-04d3-c847-643e-d242d8f6ba06@netscape.net>

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@netscape.net> 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


  reply	other threads:[~2022-06-17 13:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b62fbc602a629941c1acaad3b93d250a3eba33c0.1647222184.git.brchuckz.ref@netscape.net>
2022-03-14  3:41 ` [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion Chuck Zmudzinski
2022-03-15 11:38   ` Jan Beulich
2022-03-15 18:31     ` Chuck Zmudzinski
2022-03-16  1:27     ` Chuck Zmudzinski
2022-03-16 12:18       ` Chuck Zmudzinski
2022-03-28 21:31     ` Chuck Zmudzinski
2022-03-18  8:13   ` Jan Beulich
2022-03-30 18:45     ` Jason Andryuk
2022-03-31  4:34       ` Chuck Zmudzinski
2022-03-31 12:23         ` Jason Andryuk
2022-03-31 13:57           ` Chuck Zmudzinski
2022-04-01 13:21       ` Chuck Zmudzinski
2022-04-01 13:41         ` Chuck Zmudzinski
2022-04-01 13:49           ` Jason Andryuk
2022-04-06  1:31         ` Chuck Zmudzinski
2022-04-06 13:10           ` Jason Andryuk
2022-04-06 15:24             ` Chuck Zmudzinski
2022-04-06 17:39             ` Chuck Zmudzinski
2022-03-30 17:15   ` Anthony PERARD
2022-03-30 17:27     ` Andrew Cooper
2022-03-31  3:54       ` Chuck Zmudzinski
2022-03-31 12:29         ` Jason Andryuk
2022-03-31 14:05           ` Chuck Zmudzinski
2022-03-31 14:19             ` Jason Andryuk
2022-03-31 19:44               ` Chuck Zmudzinski
2022-06-17 13:46                 ` Anthony PERARD [this message]
2022-06-17 20:39                   ` Chuck Zmudzinski
2022-03-31  2:41     ` Chuck Zmudzinski
2022-03-31 18:32     ` Chuck Zmudzinski
2022-04-01  0:27       ` Chuck Zmudzinski
2022-03-31 23:23     ` Chuck Zmudzinski
2022-06-04  1:10     ` Chuck Zmudzinski
2022-06-06 18:47       ` Chuck Zmudzinski
     [not found] <b11b0b13-4f10-7d77-d02d-bb9a22bce887@netscape.net>
2022-03-15 17:25 ` Chuck Zmudzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YqyFoPJ8Bv9EnO5N@perard.uk.xensource.com \
    --to=anthony.perard@citrix.com \
    --cc=amc96@srcf.net \
    --cc=brchuckz@netscape.net \
    --cc=jandryuk@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.