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
