[Top][All Lists]

[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~

reply via email to

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