Re: qemu device model question

[Wei Liu <wei.liu2@citrix.com>]

On Wed, May 13, 2015 at 04:44:03PM +0200, Juergen Gross wrote:
> On 05/13/2015 03:06 PM, 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.
> 
> Indeed.
> 
> I think it would be easy to add a configuration item in the domain's
> config file to start qemu unconditionally. Another add-on could be an
> item in xl.conf to configure the default behaviour.
> 
> >Also QEMU has a mode called attach mode. Never use it personally
> >though.
> 
> A quick search of the qemu docs didn't show anything. What is it and how
> could it help?
> 

All I know is there is a QEMU option called -xen-attach. QEMU will
attach to an existing domain. Again, I never use that personally so I'm
not sure if it does what you need or the appropriate infrastructure
to start QEMU in that mode is in place. I just mentioned it for
completeness.

Wei.

> >
> >>
> >>>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.
> 
> We could either specify the qemu pid for each backend in xenstore or we
> could start qemu with a parameter indicating which backend it should
> provide.
> 
> In case we are doing something like this we should construct an
> interface capable of splitting up even per device, in case we need more
> than one process e.g. for the qdisks of one domain.
> 
> 
> Juergen