[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.