----- Original Message ----- > From: "Peter Maydell" <peter.mayd...@linaro.org> > To: "Igor Mammedov" <imamm...@redhat.com> > Cc: qemu-devel@nongnu.org > 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 <imamm...@redhat.com> 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 > >
