[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]
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
