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:43:33 +0100 Message-ID: <20150513154333.GC22118@zion.uk.xensource.com> References: <55531142.6040304@suse.com> <1431509440.8263.237.camel@citrix.com> <20150513130602.GB22118@zion.uk.xensource.com> <1431523593.8263.274.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1431523593.8263.274.camel@citrix.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: Ian Campbell Cc: Juergen Gross , "xen-devel@lists.xensource.com" , Wei Liu List-Id: xen-devel@lists.xenproject.org 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. >