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

Mark Cave-Ayland <[email protected]> Tue, 14 Jul 2026 22:57:14 +0100
Newsgroups org.nongnu.qemu-trivial,org.nongnu.qemu-devel
Message-ID <[email protected]>
On 13/07/2026 13:10, Philippe Mathieu-Daudé wrote:

> On 6/7/26 19:29, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> On 30/6/26 00:20, Mark Cave-Ayland wrote:
>>> On 29/06/2026 14:43, Thomas Huth wrote:
>>>
>>>> On 09/06/2026 08.02, Thomas Huth wrote:
>>>>> On 08/06/2026 23.29, Mark Cave-Ayland wrote:
>>>>>> On 08/06/2026 09:26, Michael Tokarev wrote:
>>>>>>
>>>>>>> On 30.04.2026 12:50, Thomas Huth wrote:
>>>>>>>> On 09/03/2026 19.14, Thomas Huth wrote:
>>>>>>>>> From: Thomas Huth <[email protected]>
>>>>>>>>>
>>>>>>>>> When trying to plug a PCI device to a Sparc64 machine, you currently
>>>>>>>>> have to specify the right bus ("bus=pciB"), otherwise you get this error:
>>>>>>>>>
>>>>>>>>>   $ qemu-system-sparc64 -device virtio-scsi-pci
>>>>>>>>>   qemu-system-sparc64: -device virtio-scsi-pci: PCI: no slot/ function
>>>>>>>>>   available for virtio-scsi-pci, all in use or reserved
>>>>>>>>>
>>>>>>>>> This is quite annoying for the unexperienced users, and it also breaks
>>>>>>>>> e.g. the iotests ("make check-block") when running with qemu- system- sparc64.
>>>>>>>>>
>>>>>>>>> Mark the non-usable PCI busses as full now, so that QEMU can automatically
>>>>>>>>> plug new PCI devices to the right "pciB" bus.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Thomas Huth <[email protected]>
>>>>>>>>> ---
>>>>>>>>>   v2: Do the change in the machine code, not in the sabre device
>>>>>>>>>
>>>>>>>>>   hw/sparc64/sun4u.c | 7 +++++++
>>>>>>>>>   1 file changed, 7 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
>>>>>>>>> index b8bda1eb816..37539535c6c 100644
>>>>>>>>> --- a/hw/sparc64/sun4u.c
>>>>>>>>> +++ b/hw/sparc64/sun4u.c
>>>>>>>>> @@ -723,6 +723,13 @@ static void sun4uv_init(MemoryRegion *address_space_mem,
>>>>>>>>>       fw_cfg_add_i16(fw_cfg, FW_CFG_SPARC64_DEPTH, graphic_depth);
>>>>>>>>>       qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>>>>>>> +
>>>>>>>>> +    /*
>>>>>>>>> +     * Mark internal PCI busses as full so that the plugging of additional
>>>>>>>>> +     * PCI devices happens on the right bus that still has free slots:
>>>>>>>>> +     */
>>>>>>>>> +    qbus_mark_full(&pci_bus->qbus);
>>>>>>>>> +    qbus_mark_full(&pci_busA->qbus);
>>>>>>>>>   }
>>>>>>>>>   enum {
>>>>>>>>
>>>>>>>> Friendly ping!
>>>>>>>
>>>>>>> This, being a simple change, somehow has not been reviewed still, so
>>>>>>> it's sitting in the queue...
>>>>>>
>>>>>> Yes, apologies - I've been absolutely flat out recently, and I've got a note to 
>>>>>> take a look at this and Peter's patch as soon as I can.
>>>>>>
>>>>>> Is this fixing an urgent issue with "make check-block" or similar?
>>>>>
>>>>> It's not urgent since this has been broken forever, but yes, it fixes "make 
>>>>> check- block" for the case where sparc64 is the only available target during 
>>>>> "configure -- target-list=sparc64-softmmu" and thus the iotests run with qemu- 
>>>>> system-sparc64.
>>>> Ping!
>>>>
>>>> While it's not urgent, soft-freeze date is in a week, so it would be nice to get 
>>>> this merged before it misses another release ... WDYT?
>>>
>>> Hi Thomas,
>>>
>>> I'm still playing catch-up a bit here, but I can't immediately find my notes on 
>>> using pciA under QEMU. I think if it fixes the iotests then go ahead and merge it 
>>> for now, which gives me time in freeze to investigate any reported issues.
>>
>> I wasn't sure whether merging this patch now or wait for your update
>> during the freeze so hold my PR for a bit; today I looked a bit at it.
>>
>> Some notes:
>>
>> - pci_bus_*_slot_reserved_mask() API isn't much used. I supposed it
>>    worked for a pair of corner cases but doesn't scale (I expect it
>>    to be called in more code paths).
>>
>> - 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.
>>
>>
>> Anyway, back to the problem here, the first part is indeed as noticed
>> Thomas to use qbus_mark_full() for the root bus:
>>
>> -- >8 --
>> diff --git a/hw/pci-host/sabre.c b/hw/pci-host/sabre.c
>> index cd2328ad53f..6a8d0b6c6d2 100644
>> --- a/hw/pci-host/sabre.c
>> +++ b/hw/pci-host/sabre.c
>> @@ -400,6 +400,9 @@ static void sabre_realize(DeviceState *dev, Error **errp)
>>       s->bridgeA = PCI_BRIDGE(pci_dev);
>>       pci_bridge_map_irq(s->bridgeA, "pciA", pci_simbaA_map_irq);
>>       pci_realize_and_unref(pci_dev, phb->bus, &error_fatal);
>> +
>> +    /* Only in-built Simba APBs can exist on the root bus */
> 
> Per the manual "Up to four Advanced PCI Bridge ASICs (APB)s may be used
> with the UltraSPARC-IIi".

That sounds about right. IIRC the UPA bus used by the UltraSPARC-IIi CPU can have up 
to 32 devices connected to it which are typically CPUs, but there are also 4 UPA IDs 
reserved for APBs. However the real life Ultra-5 machine (which is the closest to 
what QEMU emulates) is physically limited to a single CPU and a single APB with two 
of the slots on the PCI bus containing the integrated Simba PCI-PCI bridges.

Which thinking about it means the comment above is wrong i.e. it should say something 
like "Only in-built Simba PCI-PCI bridges can exist on the root bus".


ATB,

Mark.