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

[Haitao Shan <maillists.shan@xxxxxxxxx>]

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()).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel