Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Bob Breuer <breuerr@mc.net>]

On 5/1/2012 1:48 PM, Mark Cave-Ayland wrote:
> On 01/05/12 07:57, Blue Swirl wrote:
> 
>>> Therefore I can't change it to my (modified) sbus_mmio_map() function
>>> because it would break other non-SPARC platforms, and AIUI there is
>>> nothing
>>> in the memory API that allows me to move a subregion to a different
>>> MemoryRegion parent, even if I can get a reference to it with
>>> sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I
>>> misunderstood something?
>>
>> Sysbus is used as a generic class for motherboard devices, there is an
>> assumption that there is no higher level bus. What we need here is a
>> full blown bus. The translations and mappigs between bus addresses and
>> motherboard addresses should be done in a Sysbus to SBus bridge
>> device, just like PCI host bridges do.
> 
> Since SBus is mapped directly to physical addresses, is this mapping not
> just 1:1? Or does it make sense to re-work all the offsets of the
> various peripherals to be from the base address of the first slot?

It would be nice to have the device offsets be relative to the slot.
User-pluggable sbus devices should be possible.

I've just pushed an update of a dbri sbus device model to github (
https://github.com/breuerr/qemu/commits/dbri-pre2 ).  This device was
built-in to at least the SS-20, but also available as an sbus add-in
card (SunLink ISDN).  There's an fcode rom so it can be probed by OBP,
and if we could get something like "-device SUNW,,DBRIe,slot=1" to work,
then a user could add it to most of the sun4m machine models.

Bob