On 3 August 2012 15:22, Anthony Liguori <anth...@codemonkey.ws> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: >> On 3 August 2012 14:50, Anthony Liguori <anth...@codemonkey.ws> wrote: >>> There ought to be a hierarchy (based on composition) that reset flows >>> through. >> >> I think saying "the reset tree is isomorphic to the composition tree" >> is making the same mistake that qbus did with "the bus tree is >> isomorphic to the composition tree". The stakes are lower for reset >> and we can probably get away with it, but it really isn't how the >> hardware works... > > It flows through the composition tree by default, but can be overridden > at any point.
That doesn't let you model situations where reset doesn't start at the root of the tree, though. (eg, reset controller wants to trigger a reset of just the CPUs, or of CPUs + board devices). > So this model should work very well for most types of virtual hardware. > But it doesn't provide for a mechanism to "after all devices are > initialized, build FDT in guest memory, then set the CPU registers to > point to it". > > There's no logical device that has a scope like that that also has the > mechanism to get that type of hook in the reset path. That's why we > need to have the QEMUMachine::reset() hook. Yeah, I see the need, but I wonder if calling it 'reset' is confusing: maybe it should be 'post-reset', 'post-realize' or something? The arm_boot code needs to do set up and run at this point too. The other oddball case for reset is ARM M-profile cores, where the initial PC is read from a vector table at reset rather than being a fixed value. At the moment the mechanism we use for this is deeply hacky: some more generic mechanism for "do this when we come out of reset but before starting to execute" might be useful there. -- PMM
