Xen project Mailing List

Sorry, I'll stick to xen-devel then, even though I am not on the list (I can change the latter of course).

Since I run xen 4.1 (specifically the precompiled 4.1.3-3ubuntu1.5) I guess I cannot apply Andrew's patch directly (unless the file hasn't changed between the versions)? But I could probably figure out where in the 4.1.3-3ubuntu1.5 sources to insert the code from the patch, if I compile it from source.

I can do some more testing throughout the weekend. Could you give me some directions on what I should test, which logs and info to provide, and how to maximize debug output from tools and from the hypervisor. That would maximize my chances to get the relevant information. I guess that at a minimum we want a failing and a succeding case with and without the change in pciif.py?

'xm dmesg' didn't show me anything unusual when testing, but that was without any added debug-keys.

Should I pastebin log outputs or should I include them in emails to keep them searchable?

/Andreas

2013/5/3 Jan Beulich <JBeulich@xxxxxxxx>

>>> On 02.05.13 at 23:07, Andreas Falck <falck.andreas.lists@xxxxxxxxx> wrote:
> Ok, I have some progress. It tried also with the device I had always
> managed to get through, the radeon 7790 gpu. This worked equally well with
> both versions of pciif.py. However, it turned out that with the changed
> version, if I pass the gpu first in the pci = [ ... ] list, the other
> devices also gets through. This was not the case with the original version
> of pciif.py.
>
> If (and only if) i order the passthrough list in the config file so that it
> says
>
> pci = [ '41:00.0', '41:00.1', '04:00.0' ]
>
> (This corresponds to GPU, HDMI audio, USB at irqs 16, 17, 19) - then
> passthrough of all devices works with the new version of pciif.py ("if
> dev.irq:"), but not with the old version ("if not self.vm.info.is_hvm() and
> dev.irq:"). So the second failure seemingly has to do with some property
> set or checked only for the first passed through device. Logs follow:

Sending xend logs here is only marginally useful, as the errors
quite certainly originate in the hypervisor. Especially considering
that the ordering of devices matters (which is quite irritating to
me), but also with the logs here now showing the -EEXIST error
that your earlier mail mentioned, we have to rely on you to help
with tracking down the root cause of this (by instrumenting the
affected hypervisor paths, i.e. extending on the debugging
patch that Andrew sent). And without you explicitly saying so
we can't even be sure there aren't (when run at maximum log
level) already messages in the hypervisor log that might provide
some further insight.

Also, please don't cross post - pick either of xen-devel or
xen-users, but not both.

Jan

Re: [Xen-devel] PCI passthrough problems after legacy update of xen 4.1