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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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 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.


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