On 26/06/2015 18:08, Peter Maydell wrote:
On 26 June 2015 at 17:01, Paolo Bonzini wrote:
On 26/06/2015 17:54, Frederic Konrad wrote:
So what happen is:
An arm instruction want to clear tlb of all VCPUs eg: IS version of
TLBIALL.
The VCPU which execute the TLBIALL_IS can't flush tlb of other VC
Mark Burton writes:
> Paolo, Alex, Alexander,
>
> Talking to Fred after the call about ways of avoiding the ‘stop the world’
> (or rather ‘sync the world’) - we already discussed this on this thread.
> One thing that would be very helpful would be some test cases around
> this. We could then us
fred.kon...@greensocs.com writes:
> From: KONRAD Frederic
>
> Some architectures allow to flush the tlb of other VCPUs. This is not a
> problem
> when we have only one thread for all VCPUs but it definitely needs to be an
> asynchronous work when we are in true multithreaded work.
>
> TODO: Som
Paolo, Alex, Alexander,
Talking to Fred after the call about ways of avoiding the ‘stop the world’ (or
rather ‘sync the world’) - we already discussed this on this thread.
One thing that would be very helpful would be some test cases around this. We
could then use Fred’s code to check some of th
On 26/06/2015 18:08, Peter Maydell wrote:
>> > Yeah, ISTR that in some cases you have to wait for other CPUs to
>> > invalidate the TLB before proceeding. Maybe it's only when you have a
>> > dmb instruction, but it's probably simpler for QEMU to always do it
>> > synchronously.
> Yeah, the ARM
On 26/06/2015 18:35, Frederic Konrad wrote:
>>>
>> Have you tried implementing the solution based on cpu->halted?
> You mean based on cpu_has_work?
>
> Yes it was a little painfull (eg: it required cpu to be halted.. but
> maybe it's what you were suggesting?)
Yes. :) No problem, we can discus
On 26/06/2015 18:31, Paolo Bonzini wrote:
On 26/06/2015 18:30, Frederic Konrad wrote:
Yes this is not the case as I implemented it.
The rest of the TB will be executed before the tlb_flush work really
happen. The old version did this, was slow and was a mess (if two
VCPUs want to tlb_flush at
On 26/06/2015 18:30, Frederic Konrad wrote:
> Yes this is not the case as I implemented it.
>
> The rest of the TB will be executed before the tlb_flush work really
> happen. The old version did this, was slow and was a mess (if two
> VCPUs want to tlb_flush at the same time and an other
> tlb_
On 26/06/2015 18:08, Peter Maydell wrote:
On 26 June 2015 at 17:01, Paolo Bonzini wrote:
On 26/06/2015 17:54, Frederic Konrad wrote:
So what happen is:
An arm instruction want to clear tlb of all VCPUs eg: IS version of
TLBIALL.
The VCPU which execute the TLBIALL_IS can't flush tlb of other VC
On 26 June 2015 at 17:01, Paolo Bonzini wrote:
> On 26/06/2015 17:54, Frederic Konrad wrote:
>> So what happen is:
>> An arm instruction want to clear tlb of all VCPUs eg: IS version of
>> TLBIALL.
>> The VCPU which execute the TLBIALL_IS can't flush tlb of other VCPU.
>> It will just ask all VCPU
On 26/06/2015 17:54, Frederic Konrad wrote:
>>
> I think it doesn't requires to be synchronous as each VCPUs only clear
> it's own
> tlb here:
>
> void tlb_flush(CPUState *cpu, int flush_global)
> {
> CPUArchState *env = cpu->env_ptr;
>
> #if defined(DEBUG_TLB)
> printf("tlb_flush:\n");
On 26/06/2015 17:15, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
+CPU_FOREACH(cpu) {
+if (qemu_cpu_is_self(cpu)) {
+/* async_run_on_cpu handle this case but this just avoid a malloc
+ * here.
+ */
+tlb_fl
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
> +CPU_FOREACH(cpu) {
> +if (qemu_cpu_is_self(cpu)) {
> +/* async_run_on_cpu handle this case but this just avoid a malloc
> + * here.
> + */
> +tlb_flush(cpu, flush_global);
> +
From: KONRAD Frederic
Some architectures allow to flush the tlb of other VCPUs. This is not a problem
when we have only one thread for all VCPUs but it definitely needs to be an
asynchronous work when we are in true multithreaded work.
TODO: Some test case, I fear some bad results in case a VCPU
14 matches
Mail list logo
