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


[Xen-devel] Re: Comments on Xen bug 1732

To: "Haitao Shan" <maillists.shan@xxxxxxxxx>
Subject: [Xen-devel] Re: Comments on Xen bug 1732
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 31 Jan 2011 13:18:25 +0000
Cc: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 31 Jan 2011 05:19:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=K3+4Rbpuz512X4E1Pp-gDKVd2qwwVM7RQ+XMV@xxxxxxxxxxxxxx>
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: <AANLkTi=K3+4Rbpuz512X4E1Pp-gDKVd2qwwVM7RQ+XMV@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 31.01.11 at 05:54, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
After taking a closer look:

> As you may already notice the bug 1732, (
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1732), the culprit is
> c/s 22182.

The warnings are a result of the c/s, but if there are functionality
problems, they shouldn't be caused by this: The MSI-X table's base
address was always determined from the value passed from Dom0
(the raw address found in the BAR) plus the table offset as found
in the MSI-X capability structure.

> I see the following attached code in your patch. It is pointless to check
> msi->table_base against the value read from physical device if this function
> is a virtual function of SR-IOV device. VFs are required to have BARs zeroed
> by specifications. And for VFs, unless you can read these values from
> corresponding PF, you will have to trust the "table_base" passed from dom0
> via hypercall. Actually, this parameter is specifically introduced for
> enabling SR-IOV.

One important question then is whether there's a way for Xen to
determine the PF for the VF and the correct BAR to use without
additional help from Dom0. If that's not possible, passing down the
BAR contents needed for the PBA base address calculation on a
VF would be necessary, which would require a new sub-hypercall.

The only exception to this would be if both use the same BAR (and
really if that's a common case, a simple initial fix could be to use
the passed down table_base value also for pba_paddr if the two
BIRs match).

In any case I am of the opinion that all of the warnings make
sense currently, with the sole exception of the VF case of the
msi->table_base != read_pci_mem_bar() one (avoiding this
would require Xen to at least have a way to recognize a given
<bus>:<dev>.<func> is a VF).

> BTW: I vaguely recall that MSI-X table base might not be the first page of
> the corresponding BAR register.

Indeed - that's what is being accounted for using table_offset (read
from MSI-X capability structure + msix_table_offset_reg()).


Xen-devel mailing list