Re: [Qemu-devel] [PATCH 19/24] qdev: move reset handler list from vl.c to qdev.c

[Andreas Färber]

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