Re: [Xen-devel] qemu device model question

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, May 13, 2015 at 02:26:33PM +0100, Ian Campbell wrote:
> On Wed, 2015-05-13 at 14:06 +0100, Wei Liu wrote:
> > On Wed, May 13, 2015 at 10:30:40AM +0100, Ian Campbell wrote:
> > > On Wed, 2015-05-13 at 10:54 +0200, Juergen Gross wrote:
> > > > Hi,
> > > > 
> > > > while trying to build a pvusb backend in qemu I think I've found a
> > > > general issue in xl: qemu for pv-domains is started only at domain
> > > > creation and only if there is at least one backend in qemu required.
> > > > 
> > > > If there is no qemu process started for the domain at creation time
> > > > it will be impossible to successfully add such a device later while
> > > > the domain is running.
> > > > 
> > > > Are there any plans to remove that restriction? Or have I missed
> > > > some mechanism in xl to start qemu at a later time?
> > > 
> > > I think it would be reasonable to have some way to indicate that pvusb
> > > support is desired even if there are no such devices on boot, and for
> > > libxl to start the necessary backend in that case.
> > > 
> > > s/pvusb/whatever/
> > 
> > libxl__need_xenpv_qemu comes to mind.
> > 
> > Also QEMU has a mode called attach mode. Never use it personally
> > though.
> > 
> > > 
> > > > Related to this problem is the question whether it would be desirable
> > > > to have e.g. qdisk and pvusb backends in the same process possibly
> > > > influencing each others throughput.
> > > 
> > > Dissagregation of qemu's PV functionality would be nice, but I'm not
> > > sure how easy/hard it would be.
> > > 
> > 
> > At least we would need to invent a new xenstore protocol to support
> > multiple emulator.
> 
> I didn't think we were talking about emulators, just pv backend (so
> qdisk, qpvusb etc), those all have existing xenstore protocols based on
> the backend dirs, all which would be needed would be a way to tell qemu
> which backends a given process should take care of.
> 

Yes, you're right.

Wei.

> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel