[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 RFC Zisslpcfi 3/9] target/riscv: implements CSRs and new b
From: |
Deepak Gupta |
Subject: |
Re: [PATCH v1 RFC Zisslpcfi 3/9] target/riscv: implements CSRs and new bits in existing CSRs in zisslpcfi |
Date: |
Wed, 15 Feb 2023 21:20:29 -0800 |
On Wed, Feb 15, 2023 at 6:44 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/15/23 15:38, Deepak Gupta wrote:
> > Question:
> > I'll basically need two bits (one for forward cfi and one for backward cfi).
>
> Are they separately enabled? It may also be possible to use a single bit and
> then perform
> a runtime check. I guess I should read the spec...
There is a master enable but there're controls to individually enable & disable.
Thus the CPU could be in a state where one is enabled and other is not.
>
> > But I need to throw away the TB if cfi enabling bits mismatch at the
> > time TB was generated and the current state of enabling bits.
> > Reason being, this needs to get translated again and zimops need to be
> > generated.
> >
> > What's the best way to throw away a single TB?
>
> You don't throw TBs away at all.
>
> The current cpu state is produced by cpu_get_tb_cpu_state. This is included
> into the hash
> table lookup and will only match a TB which has been generated with the same
> state. Which
> means that you can have multiple live TBs, those with CFI enabled and those
> without, and
> the correct one will be selected at runtime.
>
Thanks a lot. I see `tb_lookup` & `tb_htable_lookup`.
I'll revise and add some bits in TB_FLAGS for both of them.
And probably ask some questions on the list if anything is not clear to me.
>
> r~