Just ping, any concern about this? Thanks Tiejun
> -----Original Message----- > From: qemu-devel-bounces+tiejun.chen=intel....@nongnu.org > [mailto:qemu-devel-bounces+tiejun.chen=intel....@nongnu.org] On Behalf Of > Chen, Tiejun > Sent: Wednesday, May 21, 2014 3:08 PM > To: Gerd Hoffmann; Anthony PERARD; Daniel P. Berrange > Cc: peter.mayd...@linaro.org; xen-de...@lists.xensource.com; > m...@redhat.com; stefano.stabell...@eu.citrix.com; Kay, Allen M; > kelly.zyta...@amd.com; qemu-devel@nongnu.org; Zhang, Yang Z; > anth...@codemonkey.ws; anthony.per...@citrix.com > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > 00:02.0 for INTEL IGD > > > -----Original Message----- > > From: Gerd Hoffmann [mailto:kra...@redhat.com] > > Sent: Monday, May 19, 2014 9:51 PM > > To: Chen, Tiejun > > Cc: anthony.per...@citrix.com; stefano.stabell...@eu.citrix.com; > > m...@redhat.com; kelly.zyta...@amd.com; peter.mayd...@linaro.org; > > xen-de...@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > > anth...@codemonkey.ws; 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
