On 6/7/26 19:53, Peter Maydell wrote:
On Mon, 6 Jul 2026 at 18:29, Philippe Mathieu-Daudé <[email protected]> wrote:- Bus capacity is odd. We have a generic Bus-class @max_dev field but do not use it with PCI variants. If set, it limit the instances capacity. The capacity is tracked in the instance state, and when no @max_dev is set the only way to mark a bus full is using the qbus_mark_full() helper. Then if we remove devices, the bus remains full, and there is no helper to restore available slots.The qbus_mark_full() function is intended for the use case where a machine has a bus which in real hardware is entirely internal, so you have something like an I2C bus which has some on-board I2C devices connected to it, but there's no external socket that the user could add more to the bus for. The idea is that the machine model creates all the devices for this bus, then marks it as full. The devices never get removed from the bus, because they're hardwired in, not user-unpluggable.
Are you saying, while this happens to work correctly for the Ultrasparc Sabre PCI host bridge, this is not the appropriate API to use? I understand the I2C example when the lines are populated within a board but can't be accessed outside of it (like our CLI -devices), but what about this Sabre case, the bus is internal to the chipset; can we consider it a full bus or should we use the BusClass::max_dev property instead?
