From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: qemu device model question Date: Wed, 13 May 2015 16:47:06 +0100 Message-ID: <20150513154706.GD22118@zion.uk.xensource.com> References: <55531142.6040304@suse.com> <1431509440.8263.237.camel@citrix.com> <20150513130602.GB22118@zion.uk.xensource.com> <55536333.4000505@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <55536333.4000505@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross Cc: "xen-devel@lists.xensource.com" , Wei Liu , Ian Campbell List-Id: xen-devel@lists.xenproject.org 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