On Mon, Apr 07, 2014 at 05:16:13PM +0300, Marcel Apfelbaum wrote:
On Mon, 2014-04-07 at 17:09 +0300, Michael S. Tsirkin wrote:
On Mon, Apr 07, 2014 at 04:51:54PM +0300, Marcel Apfelbaum wrote:
I don't think we'll need that for the SHPC bridge.
Because "has shpc" => not an PCIe port. (as far as I know) Anyway, why have shpc capability but no I/O or mem to support it?
AFAIK the spec does not list reset value for this register. IIRC QEMU resets both to 0.
Thanks, what do you think about the above ? ^^^ While I am not against it, it seems redundant. It has shpc => it needs I/O or mem space.
Fair enough but it can have shpc and memory without io, or shpc and io without memory.
- read back value
value 0 means bridge does not support I/O.
A similar trick should work for other optional resources.
For express it indeed makes sense to avoid claiming IO address space. I'd try to find something more automatic though, where you don't need some kind of "disable io for this express port" config option.
Won't same trick as above work?
For express ports which can only have a single device underneath we can check whenever we have a device and if one is present already don't bother claiming extra resources for hotplug.
> + for (cap = pci_config_readb(pci->bdf, PCI_CAPABILITY_LIST); cap; > + cap = pci_config_readb(pci->bdf, cap + PCI_CAP_LIST_NEXT)) > + if (pci_config_readb(pci->bdf, cap + PCI_CAP_LIST_ID) == cap_id) > + return cap;
I would also limit this to 256 iterations, to make sure we dont' get into an infinite loop with a broken device.