HI Julien, > -----Original Message----- > From: Julien Grall <[email protected]> > Sent: 2020年11月9日 20:04 > To: Penny Zheng <[email protected]>; [email protected]; > [email protected] > Cc: Andre Przywara <[email protected]>; Bertrand Marquis > <[email protected]>; Wei Chen <[email protected]>; Kaly Xin > <[email protected]>; nd <[email protected]> > Subject: Re: [PATCH] xen/arm: Add Cortex-A73 erratum 858921 workaround > > Hi, > > On 09/11/2020 08:21, Penny Zheng wrote: > > CNTVCT_EL0 or CNTPCT_EL0 counter read in Cortex-A73 (all versions) > > might return a wrong value when the counter crosses a 32bit boundary. > > > > Until now, there is no case for Xen itself to access CNTVCT_EL0, > > and it also should be the Guest OS's responsibility to deal with > > this part. > > > > But for CNTPCT, there exists several cases in Xen involving reading > > CNTPCT, so a possible workaround is that performing the read twice, > > and to return one or the other depending on whether a transition has > > taken place. > > > > Signed-off-by: Penny Zheng <[email protected]> > > Acked-by: Julien Grall <[email protected]> > > On a related topic, do we need a fix similar to Linux commit > 75a19a0202db "arm64: arch_timer: Ensure counter register reads occur > with seqlock held"? >
I take a look at this Linux commit, it seems to prevent the seq-lock to be speculated. Using an enforce ordering instead of ISB after the read counter operation seems to be for performance reasons. I have found that you had placed an ISB before read counter in get_cycles to prevent counter value to be speculated. But you haven't placed the second ISB after reading. Is it because we haven't used the get_cycles in seq lock critical context (Maybe I didn't find the right place)? So should we need to fix it now, or you prefer to fix it now for future usage? Regards, Wei Chen > Cheers, > > -- > Julien Grall
