[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] qemu device model question



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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.