Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c

[Igor Mammedov <imammedo@redhat.com>]

On 08/01/2012 11:43 PM, Peter Maydell wrote:
> On 1 August 2012 22:25, Andreas Färber <afaerber@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
>