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

["Philippe Mathieu-Daudé" <f4bug@amsat.org>]

Hi Mark,

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.

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?

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

Regards,

Phil.