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
