Re: [PATCH v2] hw/sparc64/sun4u: Mark unusable PCI busses as full to ease device plugging

Philippe Mathieu-Daudé <[email protected]> Mon, 6 Jul 2026 22:27:23 +0200
Newsgroups org.nongnu.qemu-trivial,org.nongnu.qemu-devel
Message-ID <[email protected]>
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?