On Mon, Sep 30, 2013 at 06:01:17PM +0200, Gerd Hoffmann wrote: > Hi, > > > Yes but, same as in the initial design, > > it really makes it user's problem. > > > > So we'd have > > virtio-net-pci-conventional > > virtio-net-pci-express > > virtio-net-pci-integrated > > > > > > All this while users just really want to say "virtio" > > (that's the expert user, what most people want is for guest to be faster). > > And for the actual device emulation it makes almost no difference. xhci > exists in express and integrated variants too. The qemu-emulated device > calls pcie_endpoint_cap_init() unconditionally, so the express endpoint > capability shows up even if you plug it into the root bus. That should > be handled better. But I think that would be the only difference in the > xhci code. And even that could be handled in the pci core, for example > by making pcie_endpoint_cap_init a nop unless the device is actually is > a express endpoint from the bus topology point of view. > > Maybe PCIDeviceClass->is_express should move to PCIDevice and > PCIDeviceClass should get a supports_express field instead. > > cheers, > Gerd
Not sure why do you need is_express in PCIDevice. We already have QEMU_PCI_CAP_EXPRESS set in cap_present.