All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	qemu-devel@nongnu.org, xen-devel@lists.xen.org,
	stefano.stabellini@citrix.com, kraxel@redhat.com
Subject: Re: [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough
Date: Thu, 26 Feb 2015 16:17:13 +0000	[thread overview]
Message-ID: <1424967433.14641.96.camel__25046.2925447666$1424967731$gmane$org@citrix.com> (raw)
In-Reply-To: <54EEBEBE.10108@intel.com>

On Thu, 2015-02-26 at 14:35 +0800, Chen, Tiejun wrote:

> > If we are going to do this then I think we need to arrange for the
> > interface to be able to express the need to force the workarounds for a
> > particular device. IOW a boolean will not suffice since it doesn't
> > indicate that IGD workarounds are needed.
> >
> > Probably it would be simplest to just leave this functionality out for
> > the time being and revisit if/when maintaining the list becomes an
> > annoyance or an end user trips over it.
> >
> 
> You mean we should maintain one list to save all targeted devices, then 
> tools uses ids as an index to lookup this list to pass something to qemu.

I (think I) meant a list of pci vid:did in libxl, which is matched
against the devices passed to the domain (e.g. "pci = [...]" in xl cfg),
which then enables the igd workarounds, i.e. by passing the option to
qemu.

> But actually one question that I have always been thinking about is, its 
> really a responsibility of Xen to determine which device type should be 
> passed by probing that pair of vendor and device ids? Xen is just one of 
> so many approaches to qemu so such a rare workaround option can be 
> passed actively by any user, instead of Xen. Furthermore, its becoming 
> flexible as well to those cases we want to force overriding this.

I'm not sure, but I think you are suggestion that qemu should autodetect
this situation, without being explicitly told "igd-passthru=on" on the
command line?

If the qemu maintainers are amenable to that, and it's not already the
case that other components (e.g. hvmloader) need to be told about these
workarounds, then I suppose that would work.

> So I think qemu should mainly plays this role. If qemu realizes we're 
> passing through a IGD or other targeted device, it should post a warning 
> or even error message to indicate what right behavior is needed, or what 
> is that potential risk by default.

Hrm, here it sounds more like you are suggesting that qemu should detect
and warn, rather than detect and do the right thing?

I'm not sure how Qemu could indicate what the right behaviour is going
to be, it'll differ for different hypervisors or even for which Xen
toolstack (xl vs libvirt etc) is in use.

Or maybe I've misunderstood?

Ian.

  parent reply	other threads:[~2015-02-26 16:17 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02  1:17 [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough Tiejun Chen
2015-02-02 11:08 ` Ian Campbell
2015-02-02 11:08 ` [Qemu-devel] " Ian Campbell
2015-02-03  1:00   ` Chen, Tiejun
2015-02-03  1:00   ` Chen, Tiejun
2015-02-02 12:19 ` Wei Liu
2015-02-02 12:19 ` [Qemu-devel] " Wei Liu
2015-02-02 12:54   ` Ian Jackson
2015-02-03  1:04     ` Chen, Tiejun
2015-02-03 11:07       ` Ian Campbell
2015-02-04  1:34         ` Chen, Tiejun
2015-02-04  1:34         ` [Qemu-devel] " Chen, Tiejun
2015-02-04 10:41           ` Ian Campbell
2015-02-04 10:41           ` [Qemu-devel] " Ian Campbell
2015-02-05  1:22             ` Chen, Tiejun
2015-02-05  9:52               ` [Qemu-devel] [Xen-devel] " Ian Campbell
2015-02-06  1:01                 ` Chen, Tiejun
2015-02-06  1:01                 ` [Qemu-devel] [Xen-devel] " Chen, Tiejun
2015-02-09  6:28                   ` Chen, Tiejun
2015-02-09 11:05                     ` Ian Campbell
2015-02-09 11:05                       ` [Qemu-devel] " Ian Campbell
2015-02-11  2:45                       ` [Qemu-devel] [Xen-devel] " Chen, Tiejun
2015-02-13  1:14                         ` [Qemu-devel] " Chen, Tiejun
2015-02-13  1:14                         ` [Qemu-devel] [Xen-devel] " Chen, Tiejun
2015-02-18 13:22                         ` Ian Campbell
2015-02-26  6:35                           ` Chen, Tiejun
2015-02-26 16:17                             ` Ian Campbell
2015-02-27  6:28                               ` [Qemu-devel] " Chen, Tiejun
2015-02-27  6:28                               ` [Qemu-devel] [Xen-devel] " Chen, Tiejun
2015-02-27 11:04                                 ` Ian Campbell
2015-03-02  1:20                                   ` [Qemu-devel] " Chen, Tiejun
2015-03-02  1:20                                   ` [Qemu-devel] [Xen-devel] " Chen, Tiejun
2015-03-03 10:06                                     ` Chen, Tiejun
2015-03-03 10:06                                     ` [Qemu-devel] " Chen, Tiejun
2015-03-05 17:24                                     ` Ian Campbell
2015-03-05 17:24                                     ` [Qemu-devel] [Xen-devel] " Ian Campbell
2015-02-27 11:04                                 ` [Qemu-devel] " Ian Campbell
2015-02-26 16:17                             ` Ian Campbell [this message]
2015-02-26  6:35                           ` Chen, Tiejun
2015-02-18 13:22                         ` Ian Campbell
2015-02-11  2:45                       ` Chen, Tiejun
2015-02-09  6:28                   ` Chen, Tiejun
2015-02-05  9:52               ` Ian Campbell
2015-02-05  1:22             ` Chen, Tiejun
2015-02-03 11:07       ` Ian Campbell
2015-02-03  1:04     ` Chen, Tiejun
2015-02-02 12:54   ` Ian Jackson
2015-02-03  1:01   ` Chen, Tiejun
2015-02-03  1:01   ` [Qemu-devel] " Chen, Tiejun
2015-02-03 10:19     ` Wei Liu
2015-02-04  0:41       ` Chen, Tiejun
2015-02-04  0:41       ` [Qemu-devel] " Chen, Tiejun
2015-02-03 10:19     ` Wei Liu

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='1424967433.14641.96.camel__25046.2925447666$1424967731$gmane$org@citrix.com' \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tiejun.chen@intel.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.