On 1 August 2012 22:25, Andreas Färber <afaer...@suse.de> wrote: > Am 01.08.2012 22:47, schrieb Anthony Liguori: >> Relying on the CPU list for this isn't very QOM-like. A better approach >> would be to make all CPUs appear in a container and then have the reset >> propagate through container. > > That doesn't work since our CPU modelling was going to be machine/SoC > specific. For x86, agreement seemed to be /machine/cpu[n]. For ARM, > Peter requested path/to/SoC/cortex/cpu[n].
I don't think I got that specific (and I definitely wouldn't have suggested using 'cortex' outside the context of a product name like that). I do think that there should be a container with the 4 (or whatever) CPUs, 4 timers, GIC, etc, similarly to the way the hardware is a selfcontained unit. (And that unit would then sit in a container with the other devices that live in the SoC). I don't think that's hugely different from how an x86 model would look. (The phrasing I tend to use is "one cpu with 4 cores", but if QEMU in general is going to call a single cpu core a "cpu" that's fine. We do need a term for the thing with all the cores, though...) >> Reset is a complicated beast. While we model a single reset line today, >> this isn't technically correct. I believe the distinction between reset >> types start to matter with PCI-e actually. We already have one system (exynos) that would like to model a difference between system hard reset and warm reset of some kind. But really unless we want to bite the bullet and actually model reset properly (ie as a set of Pins wired up by the machine model, with no particular magic behaviour) it's always going to be a 'this kind of works and isn't too ugly to deal with' compromise, and I don't have very strong feelings about exactly how we compromise. -- PMM
