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] SR-IOV problems - HVM cannot access network

To: David White <dwhite@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] SR-IOV problems - HVM cannot access network
From: "Rose, Gregory V" <gregory.v.rose@xxxxxxxxx>
Date: Tue, 1 Mar 2011 14:41:32 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 01 Mar 2011 14:42:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D6D6C86.10301@xxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D6D49A3.90902@xxxxxxxxxxxxx> <43F901BD926A4E43B106BF17856F0755013E8C762B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D6D6C86.10301@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvYXLbzATkNWCxGSoafbn7NBIpuPwABCoQw
Thread-topic: [Xen-devel] SR-IOV problems - HVM cannot access network
> -----Original Message-----
> From: David White [mailto:dwhite@xxxxxxxxxxxxx]
> Sent: Tuesday, March 01, 2011 2:05 PM
> To: Rose, Gregory V
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] SR-IOV problems - HVM cannot access network

> The guest driver does not seem to be the source of this difference,
> since these qemu logs are logged before HVM grub menu appears (and hence
> before guest kernel is loaded)
> Why would a physical function invoke MSI-X but not a virtual function?

A lot of reasons actually :-).  SR-IOV is a complete platform solution and 
feature.  It requires full support from all PCIe devices from the root complex 
to the endpoint device as well as proper BIOS programming and OS support.

I don't know that Ubuntu actually supports SR-IOV and I don't know which 
platform you're using and whether it supports SR-IOV.

> Is it something that pciback is doing?
> When I bind a PF to pciback, the xen-pciback driver shows:
> [ 1390.090693] pciback 0000:04:00.1: seizing device
> [ 1390.095417] xen_allocate_pirq: returning irq 17 for gsi 17
> [ 1390.101021] Already setup the GSI :17
> [ 1390.104717] pciback 0000:04:00.1: PCI INT B -> GSI 17 (level, low) ->
> IRQ 17
> [ 1390.111807] pciback 0000:04:00.1: PCI INT B disabled
> but when I bind a VF to pciback, the driver shows:
> [ 1439.411763] pciback 0000:04:10.0: seizing device
> [ 1439.416462] pciback 0000:04:10.0: enabling device (0000 -> 0002)
> (note no INT or GSI messages)
> could pciback be the source of the HVM INTx problem?

Well it's certainly possible but another good possibility is that the machine 
doesn't actually implement the SR-IOV feature correctly in the BIOS.  What 
machine are you using?  Is there a BIOS setting to enable SR-IOV and if so are 
you sure you've enabled it?

Also, would it be possible to get a register dump of the VF device from both 
the Dom0 host domain and the DomU guest domain using the Intel ethregs utility? 
 You can get that from source forge.

- Greg

Xen-devel mailing list