docs: Be consistent about capitalization of 'Arm'

The PCI addon card hardware has been selected as the first CAN

interface to implement because such device can be easily connected

to systems with different CPU architectures (x86, PowerPC, ARM, etc.).

to systems with different CPU architectures (x86, PowerPC, Arm, etc.).

The project has been initially started in frame of RTEMS GSoC 2013

slot by Jin Yang under our mentoring  The initial idea was to provide generic

    atomic_xchg(ptr, val) for stores

However, they are quite expensive on some platforms, notably POWER and

ARM.  Therefore, qemu/atomic.h provides two primitives with slightly

Arm.  Therefore, qemu/atomic.h provides two primitives with slightly

weaker constraints:

    typeof(*ptr) atomic_mb_read(ptr)

a POWER and an x86 board can run the same code to emulate a PCI network

card, even though the boards use different PCI host bridges, and they

can run the same code to emulate a SCSI disk while using different

SCSI adapters.  ARM, s390 and x86 boards can all present a virtio-blk

SCSI adapters.  Arm, s390 and x86 boards can all present a virtio-blk

disk to their guests, but with three different virtio guest interfaces.

Each QEMU target enables a subset of the boards, devices and buses that

or bus fabric.)

Each CPU has an AddressSpace. Some kinds of CPU have more than

one AddressSpace (for instance ARM guest CPUs have an AddressSpace

one AddressSpace (for instance Arm guest CPUs have an AddressSpace

for the Secure world and one for NonSecure if they implement TrustZone).

Devices which can do DMA-type operations should generally have an

AddressSpace. There is also a "system address space" which typically

(Current solution)

MMIO access automatically serialises hardware emulation by way of the

BQL. Currently ARM targets serialise all ARM_CP_IO register accesses

BQL. Currently Arm targets serialise all ARM_CP_IO register accesses

and also defer the reset/startup of vCPUs to the vCPU context by way

of async_run_on_cpu().

Aside from explicit standalone memory barrier instructions there are

also implicit memory ordering semantics which comes with each guest

memory access instruction. For example all x86 load/stores come with

fairly strong guarantees of sequential consistency where as ARM has

fairly strong guarantees of sequential consistency whereas Arm has

special variants of load/store instructions that imply acquire/release

semantics.

The second type offer a pair of load/store instructions which offer a

guarantee that a region of memory has not been touched between the

load and store instructions. An example of this is ARM's ldrex/strex

load and store instructions. An example of this is Arm's ldrex/strex

pair where the strex instruction will return a flag indicating a

successful store only if no other CPU has accessed the memory region

since the ldrex.

The TCG provides a number of atomic helpers (tcg_gen_atomic_*) which

can be used directly or combined to emulate other instructions like

ARM's ldrex/strex instructions. While they are susceptible to the ABA

Arm's ldrex/strex instructions. While they are susceptible to the ABA

problem so far common guests have not implemented patterns where

this may be a problem - typically presenting a locking ABI which

assumes cmpxchg like semantics.