WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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