qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Atomic Instructions - comments please


From: Lluís Vilanova
Subject: Re: [Qemu-devel] Atomic Instructions - comments please
Date: Mon, 15 Dec 2014 12:15:02 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

Mark Burton writes:

> We will roll a patch for this approach shortly.
> For the ‘better’ approach - I think it’s something we will consider doing…. 
> but as you say, one thing at a time.
> I dont think it will be too bad to implement, given what already exists in the
> tlb’s - (except if we have to protect (for some architecture or other) against
> non-atomic reads from an address marked atomic, I think).  I think we can 
> treat
> this independently (unless we discover that it won’t work without :-) )

I think something similar was discussed before, but you can also hybridize the
current approach with mprotect. The main problem I see is that every CPU TLB
will have to mmap+mprotect a host page (a different host page for every guest
CPU page table, but not necessarily every guest CPU).

On the bright side, that will avoid locks in the fast path. Instead of locking,
the fast path can rely on mprotect and only check if the target page contains
data or non-translated code in the case of writes. Otherwise you must resort to
locking, but that can be moved to a non-faulting slow path.

This should leave a fast path with the same complexity of today's, but I'm not
sure about the amount of overheads this would add to other paths (and how
frequent they'll be).


Best,
  Lluis




> Cheers

> Mark.

>> On 15 Dec 2014, at 14:28, Peter Maydell <address@hidden> wrote:
>> 
>> On 15 December 2014 at 12:56, Mark Burton <address@hidden> wrote:
>>> One proposal is ‘simply’ to add a mutex around this code, such
>>> that multi-threaded TCG will correctly update/read these saved
>>> address/values.
>>> This _should_ maintain the status-quo. Things that were broken
>>> before will remain broken, nothing new should break. The concern
>>> is that the fact that the TCG was previously uni-threaded MAY be
>>> masking problems with this code that we are not taking into account.
>> 
>> 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.
>> 
>> -- PMM


-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth



reply via email to

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