Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD

["Chen, Tiejun" <tiejun.chen@intel.com>]

> -----Original Message-----
> From: Anthony PERARD [mailto:anthony.perard@citrix.com]
> Sent: Tuesday, May 20, 2014 10:45 PM
> To: Chen, Tiejun
> Cc: Gerd Hoffmann; stefano.stabellini@eu.citrix.com; mst@redhat.com;
> Kelly.Zytaruk@amd.com; peter.maydell@linaro.org;
> xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org;
> anthony@codemonkey.ws; Zhang, Yang Z
> Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve
> 00:02.0 for INTEL IGD
> 
> On Mon, May 19, 2014 at 12:04:14PM +0000, Chen, Tiejun wrote:
> > > -----Original Message-----
> > > From: Gerd Hoffmann [mailto:kraxel@redhat.com]
> > > Sent: Monday, May 19, 2014 7:23 PM
> > > To: Chen, Tiejun
> > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com;
> > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org;
> > > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org;
> > > jean.guyader@eu.citrix.com; anthony@codemonkey.ws; Zhang, Yang Z
> > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough:
> > > reserve
> > > 00:02.0 for INTEL IGD
> > >
> > >   Hi,
> > >
> > > > I think '-vga none' just guarantees the qemu vga cards doesn't
> > > > occupy 00:02.0, but this doesn't mean others use this specific
> > > > slot since in qemu internal, we always pass -1 to assign a slot
> > > > automatically to register a PCI device. So in some cases, we can't
> > > > get this slot as we expect since that is already assigned previously before
> we need this.
> > >
> > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally
> > > create pci devices with auto slot assignment, which will occupy slot 2
> indeed.
> > > Use -device instead to create the devices.
> > >
> >
> > Are you saying we have to create the devices explicitly when we want to work
> IGD vga with passthrough? But how to make sure all user know this workable
> way? Maybe you suggest we should document somewhere.
> >
> > > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in
> > > > use by xen-platform
> > >
> > > Ah, the xen platform device.  /me looks.  Ah, pc_xen_hvm_init
> > > creates this automatically.  Two options here IMHO:
> > >
> > >   (1) Just move it somewhere else explicitly.  For example slot 3, or
> > >       make it a southbridge function (say 00:01.7).
> > >   (2) Don't create it automatically, instead expect management add it
> > >       if needed, using -device xen-plaform,addr=...
> > >
> > > I personally would suggest to go for #2.  As far I know the platform
> > > device is only needed if you want attach xenbus devices to the guest
> > > (correct?), so creating virtual machines without the xen platform
> > > device is a valid use case and you should allow it.
> > >
> >
> > Looks you recommend we should change current xen platform design, I'm not
> sure if something in libxl also need to be modified. Especially, this may not be
> compatible with those old xen version. And especially, how to guarantee no one
> occupy 00:02.0 in the future with auto assign?
> 
> Hi,
> 
> Libxl knows how to create a guest without xen-platform, but I think this can
> work only from QEMU 1.6 (which Xen 4.4 use).
> 
> So, using the options below with libxl would put the xen-platform device away
> from the 00:02 slot.
> xen_platform_pci=0
> device_model_args_hvm = [ '-device', 'xen-platform,addr=0x3' ]
> 

I added these two lines in domU's configuration file, but failed:

tchen0@tchen0-linux:~/workspace$ sudo xl cr domu-cfg                                                                                                       
Parsing config from domu-cfg
libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set
libxl: error: libxl_create.c:1277:domcreate_attach_pci: libxl_device_pci_add failed: -3
tchen0@tchen0-linux:~/workspace$ cat /var/log/xen/qemu-dm-HVM.log                                                                                                      
char device redirected to /dev/pts/49 (label serial0)
qemu: terminating on signal 1 from pid 3117

Anything else I'm still missing? Or this mean this way can't work based on the latest qemu/xen?

Thanks
Tiejun