[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Remove hardcoded xen-platform device initialization
Il 14/06/2013 06:38, Paul Durrant ha scritto: >>>> I think the right solution for this is to move towards using >>>> the normal "-M pc" machine. libxl can simply use "-M pc >>>> -machine accel=xen -device xen-platform-pv"; older versions >>>> that use the xenfv machine will still work. >>>> >>>> And if you do this, you will also get the benefit of >>>> versioned machine types. >>>> >> >> Thanks. I'll have a look at that. > > It's a little more complicated than I thought. There are two machine > types, xenpv and xenfv (i.e. HVM), and they share the accel=xen > option. Yes, I was talking of xenfv only. > Thus QEMU attaches to the VM in the machine code rather than > the accelerator init code. Using -M pc is therefore not an option, > unless we perhaps have separate accel options. You're talking about xen_hvm_init, right? IIRC there is a hypercall that lets you know if a domain is PV or FV so you could move large parts of it to accelerator init. What's left can be done in "if (xen_enabled())" (especially those parts that have matching TCG/KVM code in normal "-M pc" initialization, and have that code currently disabled for Xen: unifying the two or at least doing an if/else would be nicer). > Either way this > doesn't address the backwards compatibility issue. I think QEMU is > going to need to know which version of the Xen toolstack invoked it > unless we specify a compatibility matrix. Yes, "xenfv" needs to stay as legacy for compatibility purposes. But if you move the toolchain and QEMU towards using "-M pc" (requiring new QEMU for new toolchains that do) it would be a very nice cleanup. It is also needed if you ever want to support Q35/PCIe. Paolo _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |