qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Getting qemu-system-i386 to use more than one core on


From: Jakob Bohm
Subject: Re: [Qemu-discuss] Getting qemu-system-i386 to use more than one core on Cortex A7 host
Date: Mon, 4 Jan 2016 23:00:22 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 04/01/2016 22:29, Peter Maydell wrote:
On 4 January 2016 at 13:24, Jakob Bohm <address@hidden> wrote:
For your information, the x86 memory model only requires
barriers in the following cases (this is somewhat
implemented on modern machines with multiple actual x86
CPU sockets, as opposed to multicore chips, it may also
be observed when using any kind of DMA/bus-master
hardware such as GPUs):

[list elided]

This still leaves the majority of code not doing memory barriers.

This implies that x86 has no stricter restrictions on
reordering of plain loads and stores than ARM does. That
surprises me -- I thought x86's memory model imposed
stricter constraints on the implementation. (For instance
https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_.28SMP.29_microprocessor_systems
lists several cases like load-after-load that ARM might
reorder but x86 forbids reordering for.)

But I haven't looked into the details beyond mentally
tagging the situation as "here be dragons" for if/when
I ever need to review any code dealing with it.


Looking briefly at that table, I am unsure which items are covered by
those first 3 lines they say are not permitted on x86, but are
permitted on ARMv7.

The key difference I am aware of is that most traditional x86 atomic
operations are defined to also act as full memory barriers, meaning
that any memory operations that logically occur before/after the
operation also do so as seen by other CPUs (the lines in the table
marked "atomic reordered with...").


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



reply via email to

[Prev in Thread] Current Thread [Next in Thread]