[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Atomic Instructions - comments please
From: |
Mark Burton |
Subject: |
Re: [Qemu-devel] Atomic Instructions - comments please |
Date: |
Mon, 15 Dec 2014 14:43:13 +0100 |
> On 15 Dec 2014, at 14:39, Peter Maydell <address@hidden> wrote:
>
> [I'm getting bounces from address@hidden so have taken
> them off cc:
> 550 5.1.1 <address@hidden>: Recipient address rejected: User
> unknown in virtual mailbox table]
>
the address should be: address@hidden
Not sure who introduced the other address..
Cheers
Mark.
> On 15 December 2014 at 13:32, Paolo Bonzini <address@hidden> wrote:
>>
>>
>> On 15/12/2014 14:28, Peter Maydell wrote:
>>> Personally I would start out with this approach. We're going to
>>> need a "do this whole sequence atomically wrt other guest CPUs"
>>> mechanism anyway, so it's not implementing something we wouldn't
>>> otherwise need. And it's the simple thing to do. It's certainly
>>> possible to do a more architecturally correct ld/st exclusive
>>> implementation along the lines of how we manage TB invalidation
>>> with the dirty bitmap, but if we can do without it then we
>>> should try to keep the scope of this project constrained: it's
>>> a big enough job as it is.
>>
>> How would "add a mutex" work unless you add a mutex or CAS to each and
>> every qemu_st operation?
>
> Same way our current approach works -- we simply don't implement
> "stores interrupt ll/sc operations": only a store-conditional
> can break a load-locked's lock. In practice this works ok
> because the stereotypical sequences that guests use don't rely
> on this part of the spec.
>
> -- PMM
+44 (0)20 7100 3485 x 210
+33 (0)5 33 52 01 77x 210
+33 (0)603762104
mark.burton