From: Sergey Fedorov <serge.fdrv@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
sergey.fedorov@linaro.org, qemu-devel@nongnu.org
Cc: "Richard Henderson" <rth@twiddle.net>,
"Peter Crosthwaite" <crosthwaite.peter@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>
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 [thread overview]
Message-ID: <570FACF1.6020009@gmail.com> (raw)
In-Reply-To: <56FA5ADB.7030103@redhat.com>
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
next prev parent reply other threads:[~2016-04-14 14:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 13:46 [Qemu-devel] [PATCH 0/5] tcg: Misc clean-up patches from Paolo sergey.fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 1/5] tcg: code_bitmap is not used by user-mode emulation sergey.fedorov
2016-03-17 14:56 ` Peter Maydell
2016-03-17 15:03 ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 2/5] tcg: reorganize tb_find_physical loop sergey.fedorov
2016-03-17 14:59 ` Peter Maydell
2016-03-22 14:59 ` Alex Bennée
2016-03-22 15:00 ` Paolo Bonzini
2016-03-29 13:19 ` Sergey Fedorov
2016-03-29 13:26 ` Paolo Bonzini
2016-03-29 14:05 ` Sergey Fedorov
2016-03-29 14:26 ` Alex Bennée
2016-03-29 14:37 ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 3/5] tcg: always keep jump target and tb->jmp_next consistent sergey.fedorov
2016-03-17 17:57 ` Richard Henderson
2016-03-17 19:31 ` Paolo Bonzini
2016-03-17 20:45 ` Sergey Fedorov
2016-03-17 20:46 ` Richard Henderson
2016-03-18 10:29 ` Sergey Fedorov
2016-03-18 10:32 ` Sergey Fedorov
2016-03-17 13:46 ` [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate sergey.fedorov
2016-03-17 15:09 ` Paolo Bonzini
2016-03-17 15:14 ` Sergey Fedorov
2016-03-28 15:18 ` Sergey Fedorov
2016-03-28 21:21 ` Paolo Bonzini
2016-03-29 10:03 ` Sergey Fedorov
2016-03-29 10:37 ` Paolo Bonzini
2016-03-29 12:31 ` Sergey Fedorov
2016-03-29 13:43 ` Alex Bennée
2016-04-14 14:45 ` Sergey Fedorov [this message]
2016-04-14 15:13 ` Paolo Bonzini
2016-04-14 15:36 ` Sergey Fedorov
2016-04-14 17:27 ` Paolo Bonzini
2016-04-14 18:29 ` Sergey Fedorov
2016-04-14 18:37 ` Sergey Fedorov
2016-03-28 18:42 ` Sergey Fedorov
2016-03-28 20:58 ` Paolo Bonzini
2016-03-29 0:17 ` Richard Henderson
2016-03-17 13:46 ` [Qemu-devel] [PATCH 5/5] tcg: move tb_invalidated_flag to CPUState sergey.fedorov
2016-03-22 15:07 ` Alex Bennée
2016-03-22 15:11 ` Sergey Fedorov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=570FACF1.6020009@gmail.com \
--to=serge.fdrv@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=crosthwaite.peter@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=sergey.fedorov@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.