Re: [PATCH 00/20] nubus: bus, device, bridge, IRQ and address space improvements

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 12/09/2021 16:47, Philippe Mathieu-Daudé wrote:

> On 9/12/21 9:48 AM, Mark Cave-Ayland wrote:
>> This patchset is the next set of changes required to boot MacOS on the q800 machine. The
>> main aim of these patches is to improve the Nubus support so that devices can be plugged
>> into the Nubus from the command line i.e.
>>
>>      -device nubus-macfb[,romfile=decl.rom]
>>
>> At the moment the only device that can be plugged into the Nubus is the macfb framebuffer
>> however with these changes it is possible to take a ROM from a real Nubus card and
>> attempt to use it in QEMU, and also allow for future interfaces such as virtio.
>>
>> Patches 1 to 6 move the logic which manages bus addresses from the NubusDevice into
>> the NubusBus itself, including the introduction of a bitmap to manage available
>> slots on the bus.
>>
>> Patches 7 and 8 change the handling for unassigned (empty) slots to generate a bus
>> fault and add trace events to allow logging of empty slot accesses during Nubus
>> enumeration.
>>
>> Patches 9 to 11 remove the existing stubs for generating the format block (the epilogue
>> of the Nubus device embedded ROM consisting of metadata and a checksum) and replace them
>> with a romfile device property to allow the entire Nubus ROM to be loaded from a file
>> into the ROM area, similar to a PCI option ROM.
>>
>> Patch 12 moves the Nubus into its own separate address space whilst patches 13 to 17
>> update the NubusBridge (and MacNubusBridge) devices to allow machines to map the
>> required slots from the Nubus address space using sysbus_mmio_map().
>>
>> Finally patches 18 to 20 add support for Nubus IRQs and wire them up appropriately for
>> the q800 machine through VIA2, which is required for the next set of macfb updates.

Thanks for the review so far :)

> Some questions:
> 
> - TYPE_NUBUS_BRIDGE is not abstract. So far, beside
>    TYPE_MAC_NUBUS_BRIDGE, no other code use it. Could it
>    be use as it? If so, shouldn't the code in
>    mac_nubus_bridge_init() be moved to nubus_bridge_realize(),
>    creating the slot alias regions generically using the
>    slot range from slot_available_mask or using another
>    property?

Not yet, but Nubus was available on non-Apple machines. Given that TYPE_NUBUS_BRIDGE 
and TYPE_MAC_NUBUS_BRIDGE are already there, it seems a shame to prevent anyone who 
wanted to experiment with Nubus in other ways by hard-coding in the Macintosh 
restrictions.

> - Why is "slot-available-mask" a bridge device property and
>    not a bus one?

Architecturally a Nubus always has 16 slots with 1 IRQ per slot (you can compare this 
with PCI always having 32 slots with 4 possible IRQs per slot). In the Macintosh 
design Apple restricted the available address space by mapping a partial address 
range onto the CPU bus, so I'd argue that this is an implementation property of the 
bridge. And of course device properties already exist which helps make things easier 
too :)


ATB,

Mark.