This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] PCI Passthru: fn0 exported but not fn1

To: Jambunathan K <jambunathan@xxxxxxxxxx>
Subject: Re: [Xen-devel] PCI Passthru: fn0 exported but not fn1
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 27 Aug 2007 17:42:20 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Sanjeev Jorapur <sanjeev@xxxxxxxxxx>
Delivery-date: Mon, 27 Aug 2007 09:38:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46D2FD25.6080603@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfoyTw8eoN2klS8Edy1YgAWy6hiGQ==
Thread-topic: [Xen-devel] PCI Passthru: fn0 exported but not fn1
User-agent: Microsoft-Entourage/
On 27/8/07 17:34, "Jambunathan K" <jambunathan@xxxxxxxxxx> wrote:

> I didn't create any dummy device whatsoever in case of Xen304 kernel for
> fn1 to be reported in lspci. (Xen304 kernel was hand compiled from
> vanilla sources as mentioned above)
> You seem to suggest that behaviour in Xen304 was buggy and has been
> addressed with Xen310.
> I will try out the dummy device option and keep you posted.

No, I think that the behaviour in the domU (scanning all fns) was different
from native Linux behaviour in 3.0.4. This probably got fixed in 3.1.0 but
that has broken export of just fn!=0 to pcifront. The possible fixes are:
 1. Revert to scanning all fns in domU.
 2. Modify pciback to supply a dummy device of some sort on fn==0, to stop
the scan aborting.

I'll have to look into this a bit. Option 1 is probably easier.

 -- Keir

Xen-devel mailing list