On 04/30/2012 04:40 PM, Mark Cave-Ayland wrote: > On 30/04/12 14:23, Avi Kivity wrote: > > Hi Avi, > >>> 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 >> devices suffice? > > 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.
Ok, so you have a hierarchy: bus -> slot -> devices in slot? That hierarchy is present in the hardware too, or that's how I interpret "slot relative addresses". > >>> 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 >>> memory tree. >>> >> >> 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... Well, it's a lot of work -> 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. Maybe it's just wishful thinking on my part. But I always saw sysbus as a wrong interface - it corresponds to no real bus and doesn't allow hierarchy, unlike our pci or even isa implementations. > 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... > You can just follow Peter's suggestion, although qomification would be preferable IMO. -- error compiling committee.c: too many arguments to function
