Re: pci passthrough issue introduced between 4.14.1 and 4.15.0

[AL13N <alien@xxxxxxxx>]

Juergen Gross schreef op 2021-06-04 09:10:
> On 04.06.21 08:56, Jan Beulich wrote:
> > On 03.06.2021 18:01, AL13N wrote:
> > > Jan Beulich schreef op 2021-06-01 16:53:
> > > > On 01.06.2021 16:44, AL13N wrote:
> > > > > This mailing list is the correct place for the toolstack too? 
> > > > > right?
> > > > Yes.
> > > So, what's the plan to fix this? is the plan to fix the toolstack? or
> > > put your patch in kernel to kinda workaround it?
> > The patch has already been put in the kernel, as said. It would be 
> > good
> > to know whether it actually has helped your case as well.
> >
> > > Is there a way to make a regression test or unit test or something?
> > Would be nice, but may be a little difficult to arrange for in, say,
> > osstest.
> >
> > > Does anyone have an idea on what patch would cause the regression?
> > Not me, but I'm also not a tool stack maintainer (nor expert in any
> > way).
> There has been a large series by Paul Durrant [1] making heavy
> modifications in this area.
>
> Juergen
>
> [1]: 
> https://lists.xen.org/archives/html/xen-devel/2020-11/msg01680.html
Hmm after a quick look-through, nothing stands out to me; except maybe 
if the pci list gets freed after the first add, it would prevent the 
adding of the other pci devices.
Could anyone explain/point me to the place where the toolstack adds pci 
devices from the xl create vs xl pci-add?
I'm circling back to the logs of xl create having 3 log entries "Adding 
new pci device to xenstore", but only one "Creating pci backend". While 
that is normal of course, it does give out 2 possibilities i can see for 
only having 1 device:
I'm looking at this function: 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libs/light/libxl_pci.c;h=1a1c2630803b5b3b4e07f093b688e0fd5780e745;hb=e25aa9939ae0cd8317605be3d5c5611b76bc4ab4#l134 
.
possibility 1:
xs transaction at line 209 does not get called, which i presume would 
add the device to xs.
possibility 2:
xs transaction does get called, but by that time, the other end already 
has finished and thus does not look at the other devices in xs?
since xl pci-list actually does show all 3, and i see no errors, i would 
presume that for possibility 1, it can only really be line 201, but 
since this is a xl create, i'm assuming "starting" is true in this case, 
which means no lock and that line does not get called? (there is this 
weird thing where a transaction is committed and then aborted though?). 
so i guess possibility 1 is no go?
but possibility 2 would mean that unless there's another layer, the 
pcifront on the domU side would be faster than this function being 
called 3 times... which seems odd (unless this all gets done before domU 
is even started, which does not seem likely)
Of course this is all an amateur pov, i have no expertise with any of 
the xen code at all...
Well, I hope someone can take a look at this and/or help me out, please.

Maarten