From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: PV passthrough of sibling igbvf's Date: Tue, 16 Oct 2012 16:37:46 +0100 Message-ID: <507D7F4A.8020409@citrix.com> References: <507D6D84.8050602@redhat.com> <507D7240.2010305@citrix.com> <507D7774.2050902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <507D7774.2050902@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Laszlo Ersek Cc: Igor Mammedov , Drew Jones , "xen-devel@lists.xen.org" , Paolo Bonzini , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 16/10/12 16:04, Laszlo Ersek wrote: > A closer pointer into the changeset: > > http://xenbits.xensource.com/xen-unstable.hg/rev/5b433b4fca34#l16.85 > > The patch doesn't seem to justify the grouping specifically, thus I did > not even try to refute it. > > Now that you point it out, match_slot() is probably insufficient grounds > to group functions together. Maybe we should check *additionally* if the > device being passed through is multi-function. I'll try it. While that would hopefully solve the bug you have discovered, it does raise some more queries. What should we do when passing through only the first function of a multifunction device, specifically in reference to domain disagregation? I would like to hope things would just work, but I am somewhat doubtful. For SRIOV hardware, passing the physical function through should be fine (even though it is a multifunction device), as it is specifically designed to work in this way. For a CNA however, the chances of getting it working at all with different functions in different domains is unlikely at best. I just wanted to put these thoughts out in case anyone has any bright ideas about how to solve them. ~Andrew > > Thanks! > Laszlo -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com