qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [RfC PATCH 08/11] spice: add qxl device


From: Richard Henderson
Subject: Re: [Qemu-devel] Re: [RfC PATCH 08/11] spice: add qxl device
Date: Thu, 15 Apr 2010 14:27:03 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

On 04/15/2010 11:47 AM, Blue Swirl wrote:
On 4/15/10, Paolo Bonzini<address@hidden>  wrote:
On 04/14/2010 06:52 PM, Blue Swirl wrote:

On 4/14/10, Gerd Hoffmann<address@hidden>   wrote:

  +static inline void atomic_or(uint32_t *var, uint32_t add)
  +{
  +   __asm__ __volatile__ ("lock; orl %1, %0" : "+m" (*var) : "r" (add)
: "memory");
  +}


This will break on non-x86 hosts.


  I'd just use __sync_fetch_and_or here.

And on environments without __sync_fetch_and_or? Where is that available?

GCC will provide it for capable cpus.  So sparcv9 has it via CAS.

For less capable cpus, there may be cooperation with the system in
some way.  For instance, ARM, SH, and HPPA Linux kernels all provide
various mechanisms to implement atomic sequences.  The result continues
to be provided by GCC in the form of entry points in libgcc.so.

For less capable cpus with no system support... well, the program
itself needs to figure out what an appropriate response should be.
I haven't gone back to look at the context from which this snippet
was taken to know if a locally defined mutex would be adequate.

In either case, some configure tests that detect when various forms
of atomic operations are available in the host compiler would not
be amiss.


r~




reply via email to

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