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