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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.05.13 at 21:33, Andreas Falck <falck.andreas.lists@xxxxxxxxx> wrote:
> [FAILING]
> (XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
> map->pirq-1, map->bus0, map->devfn0, map->entry_nr0
> (XEN) physdev.c:131: AF2: map->type=GSI
> (XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
> map->index instead or fail with error)
> (XEN) physdev.c:188: AF3: after getting pirq: map->pirq-1, pirq0
> (XEN) physdev.c:205: AF4: got previously free pirq=16
> (XEN) physdev.c:236: AF6: final map->pirq: 16
> ...
> (XEN) physdev.c:98: AF1: map->domid1, map->type1, map->index19,
> map->pirq19, map->bus0, map->devfn0, map->entry_nr0
> (XEN) physdev.c:131: AF2: map->type=GSI
> (XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
> map->index instead or fail with error)
> (XEN) physdev.c:188: AF3: after getting pirq: map->pirq19, pirq16
> (XEN) physdev.c:219: AF4.5: pirq right before EEXIST error: 16
> (XEN) physdev.c:221: dom1: pirq 19 conflicts with irq 19

This makes matters pretty clear (minus finding the places where
the calls originate from in xend): The tool stack ought to settle on
whether it wants a 1:1 mapping for GSIs (in which case it needs to
pass in ->irq and ->index set to the same value) or whether it
wants Xen to establish a mapping (in which case it has to _always_
pass in -1 for ->pirq).

Of course we could try to work around this in the hypervisor:
Rather than calling get_free_pirq() unconditionally if map->pirq
is negative and pirq is zero, we could first see whether we can
use the 1:1 mapping slot (i.e. if it's not in use or already set up
for a 1:1 mapping). But to me that's a last resort thing, should
we find that fixing xend really isn't doable with reasonable effort.

The working case results from get_free_pirq() being first called
for IRQ16, and with a low-to-high allocation strategy this happens
to produce a 1:1 mapping (as 16 is the first slot available).

What I'm mildly concerned about is

>(XEN) physdev.c:141: AF2.5: found irq=19 (if <= 0, irq will be set to
>map->index instead or fail with error)

in both the working a failure cases - arch_domain_create() sets
up only IRQs below 16, so without any other action done by the
tool stack the translation should return zero here. But of course
that doesn't make any difference to the control flow further down
as the immediately following code - as your added messages also
states - would use map->index anyway.

Nevertheless it might be worth hunting down where that setup is
being done (domain_pirq_to_irq() simply being a read of
d->arch.pirq_irq[], it ought to be one of the few places where
that array gets written to with a positive value.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel