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

[Gerd Hoffmann <kraxel@redhat.com>]

  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.

cheers,
  Gerd