[Xen-devel] [PATCH 08/13] Xen paravirtualised PCI hotplug.

[Yosuke Iwamatsu <y-iwamatsu@xxxxxxxxxxxxx>]

Konrad Rzeszutek Wilk wrote:
> > > +       XenbusStateReconfiguring = 7,
> > > +
> > > +       XenbusStateReconfigured  = 8
> > >  };
> > >   
> > ouch.
> >
> > what's the usefulness of those 2 new states here ?
> The changes came originally from the c/s 17223, which was titled:
> Add PV passthrough PCI device hotplug support.
>
> The short summary of that is that you can dynamically attach
> PCI devices by doing: 'xm pci-attach'. And also detach by doing 'xm 
> pci-dettach'.
>
> > the xenbus state is just here to represent the connection status of the  
> > xenbus device, doesn't reconfiguring/reconfigured state is something  
> > about the underlying device more than the xenbus device ?
> I suppose it is. Thought it is more of a state of evolution - the blkback
> device could support changing of size dynamically (for example if it was mounted
> on raw LUN which changed size as well). Or if the blkback was binded to a CD-ROM
> device - support reconfiguring it (new media perhaps?).
Please also note that those two states have been already used by other devices
than pvpci, such as pvscsi and pvusb.

> > And regarding the xenbus-state state machine, what happen when you reach 8 ?
> > does every userspace handler need to handle it as a 4 ? if yes why is it  
> > not 4 ?
> Good question. Lets ask Yosuke Iwamatsu who posted the initial
> patch for this.
The state of pciback will reach 8 during the interaction between pcifront and
pciback, but in the end the state of both ends will become 4, so userspace handlers do not need to care about it indeed. 

Regards,
-- Yosuke Iwamatsu

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


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