On Thu, May 22, 2014 at 02:53:19PM +0200, Gerd Hoffmann wrote: > On Do, 2014-05-22 at 15:35 +0300, Michael S. Tsirkin wrote: > > On Thu, May 22, 2014 at 01:11:28PM +0100, Stefano Stabellini wrote: > > > On Thu, 22 May 2014, Gerd Hoffmann wrote: > > > > Patch hooks up the xen platform device to the default device code we > > > > have in qemu. Two effects: > > > > > > > > (1) The device will not be created in case -nodefaults is specified > > > > on the command line. > > > > (2) Autocreating the device is also turned off in case xen-platform > > > > is added manually via -device. > > > > > > > > With the patch applied you can move the xen-platform device to some > > > > other place with a simple 'qemu -device xen-platform,addr=$slot'. > > > > > > > > Tested-by: Tiejun Chen <tiejun.c...@intel.com> > > > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > > > > > Given that libxl always passes -nodefaults to QEMU, this patch is going > > > to effectively disable xen_platform_pci for all Xen users. It is not a > > > good idea. With the patch applied a Xen user would have no way to enable > > > xen_platform_pci except for passing some magic command line runes via > > > device_model_args_hvm. > > > > > > > Yes, it's an unfortunate use of the interface. > > How about a new machine type for xenfv - that's the only one > > that's affected, right? > > It's time xen started versioning qemu hardware anyway. > > That would do the trick for sure. Question is what versioning scheme. > Might be useful for xen machine types to version after xen releases, > i.e. xenfv-4.4 would would be supposed to be compatible with the xen-4.4 > toolstack etc. > > cheers, > Gerd >
It's much easier for us to version it with qemu machine version, like we do for pc, if that can work at all.
