qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark Cave-Ayland
Subject: Re: [PATCH 00/20] nubus: bus, device, bridge, IRQ and address space improvements
Date: Sun, 12 Sep 2021 17:56:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]