On 08/01/2012 11:43 PM, Peter Maydell wrote:
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...)
IMHO: CPU in qemu currently is more like a logical CPU.
And x86 target might need a container for them as well if we are ever to
model CPU hotplug at socket level. It could be useful for NUMA modelling
as well.
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
