Re: [Xen-devel] [PATCH 1 of 1] mini-os: PV fronted MUST be in XenbusStateConnected not XenbusStateInitialized during init

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 1 Jul 2010, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 01, 2010 at 12:32:15PM +0100, Stefano Stabellini wrote:
> > Thank you for the patch Konrad.
> > 
> > I think this fix shows us that 805ed3b20492d2f4bb465bfda65cedd286e23209
> > was the wrong fix:
> > 
> > commit 805ed3b20492d2f4bb465bfda65cedd286e23209
> > Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Date:   Fri May 21 15:46:55 2010 +0100
> > 
> >     Wait for frontend state Connected before connecting the backend
> > 
> >     The frontend of the framebuffer set a value
> >     (request-abs-pointer) and go
> >     to the state Connected.  The backend must read this value
> >     only when the
> >     frontend has the state Connected.
> > 
> > 
> > The problem was that the backend can be sure that the linux xenfb
> > frontend wrote request-abs-pointer only after the frontend state is
> > Connected.
> > In order to do that properly we need a new hook in qemu xen_backend: we
> > should probably rename the current connect hook to initialise and create
> > a new connect hook that would be implemented by xenfb to read
> > request-abs-pointer.
> 
> Uhh. How about a compromise. Lets put this hac^H^H^Hpatch in, and when the 
> QEMU
> fix is ready, yank this out and also the c/s 21260:
> 
> "mini-os: Revert 21106:b20f897d6010 "Fix xenbus initialisation"
> 
> Jeremy Fitzhardinge (jeremy@xxxxxxxx) reports that this fixes
> HVM+stubdom."
> 
> which was fixing the same exact problem I did, but on the stubdomain
> side?
> 

What you suggested, or we just revert
805ed3b20492d2f4bb465bfda65cedd286e23209 right now and wait for a proper
fix for that.

Ian, what do you think?


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