[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 19/24] qdev: move reset handler list from vl.c t
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH 19/24] qdev: move reset handler list from vl.c to qdev.c |
Date: |
Sun, 02 Dec 2012 06:44:53 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
Am 01.12.2012 12:26, schrieb Peter Maydell:
> On 30 November 2012 21:38, Eduardo Habkost <address@hidden> wrote:
>> cpu_reset() is not that well-defined, otherwise we wouldn't have this on
>> linux-user:
>>
>> #if defined(TARGET_I386) || defined(TARGET_SPARC) || defined(TARGET_PPC)
>> cpu_reset(ENV_GET_CPU(env));
>> #endif
>>
>> (I have no idea why we have that #ifdef).
>
> I think this is because the different targets disagree about whether
> the CPU should be reset on initial construction or whether it needs
> a specific reset call. (The current setup with #ifdefs is among other
> things a historical effect as a result of various refactorings in
> the past; you can trace the git history if you're interested.)
Peter and me had long IRC discussions about how to fix this in the past:
* On my qom-cpu-copy branch I have a patch queued that drops the
#ifdef above, accepting that CPUs may get reset twice then.
=> Dispels doubt for target authors; doubts about correctness though.
* PMM suggested to move cpu_clone_regs() from target-*/cpu.h to *-user/.
=> Would lead to duplication between linux-user and bsd-user; ABI?
* PMM suggested to replace cpu_copy() with ABI-specific code in *-user/.
Unfortunately I don't quite remember the details of how... ;)
The x86 APIC refactorings that Iguardo have done do bring us very close
to sane cpu_reset() semantics (ignoring the two hands full of
hard/soft/... reset variants that ppc and other architectures feature).
Declaring cpu_reset() inferior to reset handlers due to the linux-user
mess is going into the wrong direction - some targets seem to ignore
reset or fork/clone completely at the moment, so the state we see cannot
be considered fully correct.
In particular the above reset is being performed *after* cpu_copy()
memcpy()'ed random memory contents (which for some targets may contain
pointers), undoing the copying in large parts. Therefore, when all
targets reset as part of cpu_init() (or by moving the cpu_reset() call
into early cpu_copy()?) we could get rid of it in do_fork() and of its
weird conditions.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg