qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Help on TLB Flush


From: Mark Burton
Subject: Re: [Qemu-devel] Help on TLB Flush
Date: Fri, 13 Feb 2015 08:37:28 +0100

> On 13 Feb 2015, at 08:24, Peter Maydell <address@hidden> wrote:
> 
> On 13 February 2015 at 07:16, Mark Burton <address@hidden> wrote:
>> If the kernel is doing this - then effectively - for X86, each CPU only
>> flush’s it’s own TLB (from the perspective of Qemu) - correct?
>> (in which case, for Qemu itself - for x86) - we dont need to implement
>> a global flush, and hence we dont need to build the mechanism to sync ?

> The semantics you need are "flush the QEMU TLB for CPU X" (where
> X may not be the CPU you're running on). This is what tlb_flush()
> does: it takes a CPU argument to act on. (Ditto tlb_flush_page, etc.)
> We then use that to implement the target's required semantics
> (eg in ARM the tlbiall_is_write() function is handled by iterating
> through all CPUs and calling tlb_flush on them).

What Lluis implied seemed to be that the kernel arranged to signal the CPU that 
would flush. Hence, (for X86), we would only ever flush our own TLB.

> 
> If you don't want the pain of checking the semantics of every
> backend and figuring out a new set of primitives to implement,
> then what you need to do is continue to provide the guarantees
> the current tlb_flush function does: when it returns then the
> CPU it's supposed to have acted on has definitely done so.
> 
> You can try and be cleverer if you want to, but personally
> I would recommend keeping the scope of your work simple
> where you can.

yes - though keeping it simple (silly) seems to have some complexities in this 
case, which is why we are trying to reduce the guarantees that tlm_flush() 
provides. 

At present - the ‘foreach cpu, tlb_flush()’ is effectively atomic, as no other 
CPU will be executing at the same time.
Adding multi-thread, we can already say - this ‘atomicity’ isn’t strictly 
required. As you say, the only thing tlb_flush needs to guarantee is that the 
CPU concerned has flushed. 
- that already helps. And I agree with you is the right place to take 
tlb_flush().

Of course, when only the current CPU is flushed things are much simpler (and 
already handled)...


For our immediate concern, in the interests of getting the thing working and 
making sure we’ve turned over all the stones, on ARM - it MAY help us to check 
that the flush has happened ‘in the next memory barrier’….
        - I dont know if that will help us or not, and - even if it does, I 
agree with you, it would be more messy than it need be.
However, in the interests of making sure that there are no other issues - we 
may ‘hack’ something before we put in place a more elegant solution…. 
(right now, we have some mutex issues, shifting the sync to the barrier MAY 
help us avoid that…. To Be Seen…. and anyway - it would only be a temporary 
fix).

Cheers

Mark.



> 
> -- PMM


         +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210

        +33 (0)603762104
        mark.burton




reply via email to

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