Re: [Xen-devel] pci device hotplug, race accessing xenstore

[Simon Horman <horms@xxxxxxxxxxxx>]

On Fri, Oct 16, 2009 at 01:37:11PM +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2009, Simon Horman wrote:
> > > 
> > > I think we should take this chance to make the pci-insert protocol more
> > > reliable.
> > > In particular we are missing the following things:
> > > 
> > > - qemu shouldn't accept any dm-command unless it is in state "running";
> > > 
> > > - xend should remove the command node on xenstore after reading
> > > state "pci-inserted" and before writing state "running"  again.
> > > 
> > > This way when the second xenstore watch fires the pci-ins command is
> > > never executed for a second time because either qemu is not in the right
> > > state (pci-inserted instead of running) or the command node doesn't
> > > contain any data (it has been removed by xend).
> > 
> > My memory of that code is a bit hazy, but that sounds like a good idea.
> 
> Do you think you'll find the time to fix the first two issues, or
> someone else should do it?

I will try and find some time to address these issues.  Though I am
travelling for the next ~2 weeks, so its unlikely to be during that time.

> I should be able to find a solution for the stubdom coldplug problem
> myself.
> 
> > > Another problem is that nothing else can happen while xend waits for the
> > > device model to be in state running, this also prevents pci coldplug
> > > from working with stubdoms.
> > > Is it possible to run signalDeviceModel in a new xend Thread?
> > 
> > I'm interested to hear a comment on what the status of the Ocaml
> > replacement for xend is. It seems silly to spend time fixing up the
> > python code - there is ample scope for fixing - if a replacement
> > is in the wings. In particular, I'm refering to the toolstack.git
> > XCI tree.
> > 
> > 
> 
> Surely no replacement is going to be ready for the 3.5 release and I
> think if anything is going to happen it will probably be a smooth
> transition rather than an abrupt change.

Sure, but changes like adding new threads sound like fairly
major surgery to me. Perhaps I am wrong there.

My experience with the current xm/xend pass-through code is that it is very
fragile and refactoring is hard to do without introducing regressions.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel