This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: Xen 3.4 multi-function pass-through tree, isn't work

On Mon, Jul 27, 2009 at 11:03:19AM +0300, Tom Rotenberg wrote:
> Simon,
> Thanks for investing the time to solve the bugs i'm reporting.
> I must say, that the second problem i reported (the complete machine
> freeze), is much important in my opinion, so i also hope, that someone
> from the community, will give it a look, it's certainly blocking me,
> and i don't know from where to start on this issue. Anyway, i'm
> waiting for your inputs about the second problem.

I suspect you are correct. I'll try and spend some time on it very soon.

> On Mon, Jul 27, 2009 at 4:58 AM, Simon Horman<horms@xxxxxxxxxxxx> wrote:
> > On Sun, Jul 26, 2009 at 01:01:02PM +0300, Tom Rotenberg wrote:
> >> Simon,
> >>
> >> (BTW - Did you see my other mail, about a problem, which causes the
> >> machine to freeze? i suspect that this might be due to the multi-fn
> >> pass-through code. Can u please give your opinion about it?)
> >
> > Its quite likely that the problem that you are seeing is caused by
> > multi-function.  Especially as a) you are probably the only person to
> > exercise the code in this way so far and b) the PCI pass-through code is
> > in my opinion very fragile.
> >
> > I haven't looked closely into the problem yet - I was kind of hoping
> > someone else would while I was tracking down the cause of the
> > other problems that you have reported.
> >
> >> Here is the resulting log:
> >
> > [snip]
> >
> >> [2009-07-26 05:59:12 4286] INFO (XendDomainInfo:2146) Created PCI device 
> >> 0000:00:1a.0 at index 0 with state None
> >> [2009-07-26 05:59:12 4286] INFO (XendDomainInfo:2146) Created PCI device 
> >> 0000:00:1d.0 at index 1 with state None
> >
> > Thanks, that is very interesting. It looks like 0000:00:1a.0 is
> > being inserted into xenstore twice, which is invalid. I'll hunt
> > further to see if I can work out why that is occurring.

On closer examination 0000:00:1a.0 != 0000:00:1d.0, so my comment
immediately above is wrong.

What I now think is happening is that for some reason on your system 
when _createDevices() initialises the devices in xenstore using
_createDevice() then end up with no state entry. Whereas on my system
then end up with state 3=Initialised.

It seems to me that actually the behaviour of your system
is correct and my system is bogus. I really don't know why
that is the case - are you using the stock xenstore implementation
in C, or the Ocaml version?

In any case, it seems to be that your original work-around was more or less
correct. I'll just tweak it a bit to handle the case where cleanupDevices()
is shuffling entries because one or more have been deleted and repost it.

Xen-devel mailing list