From: Simon Horman <horms@verge.net.au>
To: Gianni Tedesco <gianni.tedesco@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH]: xl: pci multi-function passthrough v2
Date: Tue, 10 Aug 2010 11:25:19 -0400 [thread overview]
Message-ID: <20100810152518.GH3350@verge.net.au> (raw)
In-Reply-To: <1281439546.18490.277.camel@qabil.uk.xensource.com>
On Tue, Aug 10, 2010 at 12:25:46PM +0100, Gianni Tedesco wrote:
> On Mon, 2010-08-09 at 21:27 +0100, Simon Horman wrote:
> > On Mon, Aug 09, 2010 at 01:00:39PM +0100, Gianni Tedesco wrote:
> > > Changes since last time:
> > > 1. Incorporate Stefanos feedback wrt. coding style, commenting
> > > non-obvious code and making single-function a special-case of
> > > multi-function
> > > 2. Also fix the case for passing through a single sub-function and
> > > re-mapping it as a single-function virtual device. (ie: pfunc =
> > > non-zero, vfunc = zero). Apparently needed for SR-IOV.
> > > 3. One-liner format change in xl pci-list-assignable to make it
> > > print a copy-and-pasteable BDF.
> > > 8<----------------------------------------
> > >
> > > Implement PCI pass-through for multi-function devices. The supported BDF
> > > notation is: BB:DD.* - therefore passing-through a subset of functions or
> > > remapping the function numbers is not supported except for when passing
> > > through a single function which will be a virtual function 0.
> >
> > Is there any plan to extend this to allow for re-mapping and the like.
> > When I worked on the original multi-function support (last year)
> > this seemed to be a requirement of some people.
>
> I am glad you asked
>
> I initially planned to support this but it seemed like a nightmare:
> 1. The BDF notation practically becomes a regex language ;)
I don't think its reasonable to say it becomes a regex language.
But I do agree that it becomes more complex.
> 2. For HVM, if a function 0 is not passed through then you don't
> generate an SCI interrupt for PCI hotplug.
Isn't it sufficient to make sure that the guest sees a function 0,
regardless of what the physical function number is? Or am I missing
something?
> 3. I couldn't imagine a scenario where this wasn't erroneous thing to do
I'm not sure that I understand this point.
I agree that your system should always produce a valid result.
But I think that there are other configurations that are
both valid and useful.
> But if someone can convince me that this is a worth-while thing to do
> (3) then (1) and (2) are just technical problems which can be
> overcome...
People convinced me that it was worthwhile, but I'm not those people.
next prev parent reply other threads:[~2010-08-10 15:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-09 12:00 [PATCH]: xl: pci multi-function passthrough v2 Gianni Tedesco
2010-08-09 12:47 ` Gianni Tedesco
2010-08-09 16:47 ` Stefano Stabellini
2010-08-09 20:27 ` Simon Horman
2010-08-10 11:25 ` Gianni Tedesco
2010-08-10 15:25 ` Simon Horman [this message]
2010-08-10 15:31 ` Gianni Tedesco
2010-08-10 16:00 ` Simon Horman
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=20100810152518.GH3350@verge.net.au \
--to=horms@verge.net.au \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=gianni.tedesco@citrix.com \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).