[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c |
Date: |
Wed, 1 Aug 2012 22:43:06 +0100 |
On 1 August 2012 22:25, Andreas Färber <address@hidden> 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
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c,
Peter Maydell <=
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Igor Mammedov, 2012/08/02
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Andreas Färber, 2012/08/01
- Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c, Anthony Liguori, 2012/08/01