[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Memory API: handling unassigned physical memory
From: |
Bob Breuer |
Subject: |
Re: [Qemu-devel] Memory API: handling unassigned physical memory |
Date: |
Wed, 02 May 2012 10:15:07 -0500 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 |
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