| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
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
|
|
|
| |
|
Home