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

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

> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel@xxxxxxxxxx]
> Sent: Monday, May 19, 2014 9:51 PM
> To: Chen, Tiejun
> Cc: anthony.perard@xxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
> mst@xxxxxxxxxx; Kelly.Zytaruk@xxxxxxx; peter.maydell@xxxxxxxxxx;
> xen-devel@xxxxxxxxxxxxxxxxxxx; Kay, Allen M; qemu-devel@xxxxxxxxxx;
> anthony@xxxxxxxxxxxxx; Zhang, Yang Z
> Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve
> 00:02.0 for INTEL IGD
> 
>   Hi,
> 
> > > 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.
> 
> libvirt does this unconditionally, because it is a good idea anyway for a 
> number
> of reasons.  Example: create a machine with three pci devices, hot-unplug the
> second, then live-migrate to another machine.  The only way to create the
> correct config on the target machine is to explicitly assign slots, otherwise 
> the
> third pci device ends up in the wrong slot.
> 
> Don't know how the libxl (and xl tool) work.  Maybe it does the same anyway.
> Maybe it can handle the address assignment transparently for the user.
> 
> > > 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.
> 
> Going for (1) certainly is easier as (2) indeed will need changes in the 
> libxl, and
> might be tricky to get work with both old+new versions.
> 
> > And especially, how to guarantee no one occupy 00:02.0 in the future
> > with auto assign?
> 
> Creating devices automatically turned out to have a number of problems.
> So it is very unlikely we'll ever do this again.
> 

According to our discussions, I realize we may have some plans or policies 
dedicated to how to assign devfn, but to support GFX passthrough for XEN, I 
think currently it may be a better solution to adopt #1 simply like this:

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index eaf3e61..500b3c2 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -386,7 +386,7 @@ static void pc_xen_hvm_init(QEMUMachineInitArgs *args)
 
     bus = pci_find_primary_bus();
     if (bus != NULL) {
-        pci_create_simple(bus, -1, "xen-platform");
+        pci_create_simple(bus, PCI_DEVFN(3,0), "xen-platform");
     }
 }
 #endif

Then we can go out to plan how to assign devfn in common, is this fine?

Thanks
Tiejun

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