qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 2/5] pci: Add interface names to hybrid PCI devices
Date: Mon, 28 Aug 2017 14:59:01 -0300
User-agent: Mutt/1.8.0 (2017-02-23)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]