Re: [Qemu-devel] [PATCH 2/5] pci: Add interface names to hybrid PCI devices

[Eduardo Habkost <ehabkost@redhat.com>]

On Sun, Aug 27, 2017 at 11:33:46AM +0300, Marcel Apfelbaum wrote:
> Hi Eduardo,
> 
> On 25/08/2017 22:18, Eduardo Habkost wrote:
> > On Wed, Aug 23, 2017 at 07:14:42PM -0300, Eduardo Habkost wrote:
> > > The following devices support both PCIe and legacy PCI, by
> > > including special code to handle the QEMU_PCI_CAP_EXPRESS flag:
> > > 
> > > * vfio-pci (is_express=1, but legacy PCI handled by
> > >    vfio_populate_device())
> > > * vmxnet3 (is_express=0, but PCIe handled by vmxnet3_realize())
> > > * pvscsi (is_express=0, but PCIe handled by pvscsi_realize())
> > > * virtio-pci (is_express=0, but PCIe handled by
> > >    virtio_pci_dc_realize(), and additional legacy PCI code at
> > >    virtio_pci_realize())
> > 
> > Oh, the rules are even messier than that: QEMU_PCI_CAP_EXPRESS
> > controls _some_ of the code that makes a device become a PCI
> > Express device, but not every case.
> > 
> > In addition to vmxnet3, pvscsi and virtio-pci, PCIe caps
> > initialization is conditional on hcd-xhci (see below).
> > 
> > This means xhci is also a hybrid device.  But it doesn't seem to
> > clear QEMU_PCI_CAP_EXPRESS.  Doesn't it mean pci_config_size() is
> > broken if xhci is plugged to a legacy PCI bus?  How does it
> > affect migration?
> > 
> 
> If this is the case we reserve more config space than needed.
> Other than wasted space it should be OK, including migration.

Yeah, it looks harmless, except that we need to take the
migration format into account if refactoring that code.

-- 
Eduardo