[Qemu-devel] Atomicity of i386 guest atomic instructions

[Qemu-devel] Atomicity of i386 guest atomic instructions

[Jakub Jermar]

Hello,

is it at least theoretically possible that the guest atomic instructions (e.g. XCHG,
LOCK CMPXCHG) on target-i386 are somehow not atomic when simulated/translated by Qemu?

I am observing a problem with one of my HelenOS/ia32 builds which suggests me that for
some reason HelenOS spinlocks are not working as expected, because at one point there are 
two CPUs in one spinlock-protected critical section. I have been looking into this for
several days and could not find anything on the HelenOS side. The assembly code which
does the locking looks good and the respective spinlock is not corrupted. The problem
shows in about 2/3 of all dual-CPU boots. When it shows, the stack trace is always the
same. When it does not show during the boot, the system continues to run stable and I
never see the problem after the system started up.

I reproduced this on Qemu 0.11.1 and 0.12.2-3 without kvm, both on ia32 and amd64 hosts.

Any idea appreciated.

Regards,
Jakub

Re: [Qemu-devel] Atomicity of i386 guest atomic instructions

[Alexander Graf]

On 23.04.2010, at 19:27, Jakub Jermar wrote:

> Hello,
> 
> is it at least theoretically possible that the guest atomic instructions (e.g. XCHG,
> LOCK CMPXCHG) on target-i386 are somehow not atomic when simulated/translated by Qemu?
> 
> I am observing a problem with one of my HelenOS/ia32 builds which suggests me that for
> some reason HelenOS spinlocks are not working as expected, because at one point there are 
> two CPUs in one spinlock-protected critical section. I have been looking into this for
> several days and could not find anything on the HelenOS side. The assembly code which
> does the locking looks good and the respective spinlock is not corrupted. The problem
> shows in about 2/3 of all dual-CPU boots. When it shows, the stack trace is always the
> same. When it does not show during the boot, the system continues to run stable and I
> never see the problem after the system started up.
> 
> I reproduced this on Qemu 0.11.1 and 0.12.2-3 without kvm, both on ia32 and amd64 hosts.

They should be atomic. TCG SMP swaps between different vCPUs only after translation blocks are done. In fact, the only way I'm aware of to stop the execution of a TB mid-way is a page fault.

You can as always check things with the -d parameter.

Alex

Re: [Qemu-devel] Atomicity of i386 guest atomic instructions

[Jamie Lokier]

Alexander Graf wrote:
> They should be atomic. TCG SMP swaps between different vCPUs only
> after translation blocks are done. In fact, the only way I'm aware
> of to stop the execution of a TB mid-way is a page fault.

A page fault would interrupt it if the atomic is implemented as
a read followed by a write, and the write faults.

> You can as always check things with the -d parameter.

-- Jamie

Re: [Qemu-devel] Atomicity of i386 guest atomic instructions

[Paul Brook]

> Alexander Graf wrote:
> > They should be atomic. TCG SMP swaps between different vCPUs only
> > after translation blocks are done. In fact, the only way I'm aware
> > of to stop the execution of a TB mid-way is a page fault.
> 
> A page fault would interrupt it if the atomic is implemented as
> a read followed by a write, and the write faults.

Yes, but in that case the whole instruction should be abandoned.

Paul