Re: Comments on Xen bug 1732

[Haitao Shan <maillists.shan@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3017 bytes --]

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@novell.com>

> >>> On 31.01.11 at 05:54, Haitao Shan <maillists.shan@gmail.com> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 3905 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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