On 30/04/12 14:23, Avi Kivity wrote:
My understanding based upon this is that it would be impossible to
register a different parent MemoryRegion without duplicating the init
function for all shared devices which seems undesirable :(
What are the requirements? You need a different catch-all mmio handler
for each slot? Or would one catch-all mmio handler for all sysbus
A single catch-all for all sysbus devices would suffice, however I'm
thinking it makes sense to have one MemoryRegion per slot so that the
devices can register onto the bus using their "slot relative" address to
allow for potentially moving hardware between slots.
The only solution I can think of is to make sysbus_mmio_map() more
intelligent so that instead of blindly adding the device to the "root"
MemoryRegion, it traverses down the MemoryRegion hierarchy starting
from the root to the furtherest leaf node it can find based upon the
specified address and then adds the new subregion there. Hence if I
add my SBus memory regions first before call the various peripheral
init functions, everything should end up in the correct part of the
This solution attempts to reconstruct the memory hierarchy from the
address, instead of maintaining it in the device tree.
So I guess that is bad...
I believe this should preserve compatibility for existing sysbus API
users with just a single "root" MemoryRegion, however due to lack of
any documentation related to sysbus I'm not sure if this would break
other platforms or maybe even violate one of its key design features?
IMO the best fix is to unsysbus the device and qomify it instead. This
way we're 100% flexible in how we can attach it.
That's interesting - I didn't realise that sysbus is a legacy interface
with respect to QOM. Is there any documentation related to this? Then
again, converting all of the devices over to QOM and testing that it
doesn't break all platforms/busses suddenly becomes a huge job...