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: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: Comments on Xen bug 1732
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Tue, 1 Feb 2011 13:48:13 +0800
Cc: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 31 Jan 2011 21:49:04 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KPuqRLJBJafe+W2CQIKr35kmnAk6F3O6RBiKx7tvxpI=; b=sm8pLtyc1f1GLG6DguPXAQbpZ9nejezDro0GuuTkEZVd3ucAdP6SF7Nig+yG7DyBZJ Sr2wG1IhgYVpPM66KZ/qN6j/+LRDGc0SkO6FqUXvRmEzTbRyezuOgL/3A8g13p1TAdzr fZeFgnOaNJ507EbQxB4adZsUiP9K4zv2uSwIQ=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vb31GR8zLPP3ssEcnIVpukQsPrNnY7C5NfA7H03QvdHQ65WW58iGDqj/rvEbT/Yvce Yv2uruUQ1mw6CN7cywrsPNk+HAOVblADu+PDTSF0a5V+ReY3M8bsF9unmzI6GHwasdRn e43F96mcKnoM0BkYTjXpDD1OIeKzgTpDWM6mI=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D46C4B1020000780002F74E@xxxxxxxxxxxxxxxxxx>
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> <4D46C4B1020000780002F74E@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Jan,

My carelessness, the patch did not cause any malfunction besides these additional warning messages. :)

What I am thinking about here is:
1> Given a BDF, how can Xen determine whether it is a VFs?
2> If it is really a VF, how can Xen find its PF? For example, if a VF looks like 07:03:0, its PF might be 07:00.0 or 06:00.0 ... 
Perhaps a little assist from Dom0 would be very good.

Another question: What would the purpose of your patch be? I mean, you are trying to remove MSIX table access right for DomUs, or you are also aiming at removing msi->table_base from the trust chain so that guests cannot pass arbitrary address down to Xen?

I guess you patch already addressed the former. The latter does need a reasonable solution but it won't be a blocker for Xen 4.1 release, right?

Shan Haitao

2011/1/31 Jan Beulich <JBeulich@xxxxxxxxxx>
>>> 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
<Prev in Thread] Current Thread [Next in Thread>