qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_


From: Sergey Fedorov
Subject: Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate
Date: Thu, 14 Apr 2016 17:45:05 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 29/03/16 13:37, Paolo Bonzini wrote:
>>>> Your observation that tb->pc==-1 is not necessarily safe still holds of
>>>> >> > course.  Probably the best thing is an inline that can do one of:
>>>> >> >
>>>> >> > 1) set cs_base to an invalid value (anything nonzero is enough except 
>>>> >> > on
>>>> >> > x86 and SPARC; SPARC can use all-ones)
>>>> >> >
>>>> >> > 2) sets the flags to an invalid combination (x86 can use all ones)
>>>> >> >
>>>> >> > 3) sets the PC to an invalid value (no one really needs it)
>> >
>> > It's a bit tricky. Does it really worth doing so instead of using a
>> > separate dedicated flag? Mainly, it should cost one extra compare on TB
>> > look-up. I suppose it's a kind of trade-off between performance and code
>> > clarity.
> I think a new inline function cpu_make_tb_invalid would not be too tricky.
> Just setting "tb->cs_base = -1;" is pretty much obvious for all the targets
> that do not use cs_base at all and for SPARC which sets it to a PC (and
> thus a multiple of four).  x86 is the odd one out.

So what would you suggest to use for x86? I can't think of something
that looks like a really compelling combination when I look at
cpu_get_tb_cpu_state() in target-i386/cpu.h. Personally, I'm not so
happy trying to use pc/cs_base/flags to mark an invalid TB. Are my
worries unreasonable? :) Some other thoughts?

Anyway, I am wondering if there is still a way to clear tb_phys_hash and
tb_jmp_cache safely. Maybe something like this:
 * Remove the TB from physical hash list
 * Memory barrier
 * Remove the TB from each vCPU's virtual address hash cache

Would that work?

Kind regards,
Sergey



reply via email to

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