> On 15 Dec 2014, at 14:39, Peter Maydell <peter.mayd...@linaro.org> wrote:
>
> [I'm getting bounces from mt...@greensocs.com so have taken
> them off cc:
> 550 5.1.1 <mt...@greensocs.com>: Recipient address rejected: User
> unknown in virtual mailbox table]
>
the address should be: mt...@listserver.greensocs.com
Not sure who introduced the other address..
Cheers
Mark.
> On 15 December 2014 at 13:32, Paolo Bonzini <pbonz...@redhat.com> 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
