Re: [Qemu-devel] [PATCH next v2 73/74] linux-user: Use cpu_reset() after cpu_init() / cpu_copy()

[Igor Mammedov]

----- Original Message -----
> From: "Peter Maydell" <address@hidden>
> To: "Igor Mammedov" <address@hidden>
> Cc: address@hidden
> Sent: Wednesday, May 16, 2012 6:13:37 PM
> Subject: Re: [Qemu-devel] [PATCH next v2 73/74] linux-user: Use cpu_reset() 
> after cpu_init() / cpu_copy()
>
> On 16 May 2012 17:05, Igor Mammedov <address@hidden> wrote:
> > 1. I'd like to have cpu_reset in realizefn - which is kind of
> > equivalent
> > of cpu power-on, after which cpu should be in known state
> > (i.e. the state after reset, at least for target-i386).
>
> Realize is not the same as "has come out of reset". Consider
> CPUs where on coming out of reset they read the initial program
> counter from RAM. (We don't really handle that properly anyway,
> though.)
Yep, it certainly could be different between for other targets.
May be then it would be acceptable to do cpu_reset for target-i386
in realize at least. It matches how x86 should behave.

>
> > 2. cpu_reset in realizefn as well will free us from calling
> > cpu_reset
> > in device_add when implementing hotplug and will allow to remove it
> > from
> > hw/pc.c.
> >
> > 3. regarding exec.c:cpu_copy and do_fork on target-i386
> >  cpu_copy first creates cpu then copies all over it CPUArchState of
> >  original
> >  cpu perserving only cpu_index. It's beyond my understanding why
> >  anyone would/need do this.
> >  So I'll not touch cpu_reset in do_fork since I haven't a clue
> >  what's
> >  going on. Albeit adding cpu_reset in realizefn shouldn't break
> >  anything
> > here.
>
> The purpose of cpu_copy is to handle creating a new pthread in
> linux-user mode. The new thread is supposed to start out with
> a CPU state (as far as user mode is concerned) which is identical
> to that of its parent thread. So we create a new CPU which is
> a copy of the old one. memcpy() is a cheap hack to do this, which
> is creaking at the seams rather these days. If you delve back in
> the git history to when it was first put in it looked a bit
> cleaner...
Thanks for expanded explanation. (/me went to read history)

>
> The fact that do_fork then calls cpu_reset (for some targets) is
> a bug -- we need to call cpu_reset after cpu_init and before the
> copying of the registers, so in do_fork is too late (it wipes
> out the copied registers we've just gone to the effort of setting
> up).

And if cpu_init could be/is a combination of object_new + set properties + 
realize
then on some targets calling cpu_reset at the end of cpu_init or
at the end of realize would do the thing? :)


> -- PMM
>
>