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

["Andreas Färber" <afaerber@suse.de>]

Am 01.08.2012 23:43, schrieb Peter Maydell:
> 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).

http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg02470.html

Context was Exynos and it was <soc>/cortex-a9/core[n] to be exact; I had
suggested to place them onto the SoC directly, you wanted to refine that.

My point here is that the container is not just for the CPUs.
And if we go ahead with /machine for x86 then for the time being that is
not a device and as an Object does not have a reset mechanism that could
trigger the CPUs' reset.

I am leaning towards that a SoC should be a DeviceState but am unclear
whether a SoC should have a central reset callback triggering the CPUs'
reset. Doesn't sound like real hardware behavior to me.

> 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...)

We had that discussion too and Anthony had some aggressive refactoring
ideas CPU -> core -> thread, but I see that in the pretty distant future
still. We haven't even managed to get a single data field into CPUState
yet, which would be a prerequisite for splitting it up - my series until
today conflicting with Igor's APIC refactoring. (Still working on making
at least a baby step into that direction for 1.2!)

>>> 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.

Well, we can easily add more callback hooks to CPUClass and/or change
the implementation of my central cpu_reset(). A clear advantage over the
old decentral cpu_[state_]reset(). :-)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg