On 01.03.2022 15:39, Andrew Cooper wrote:
> On 01/03/2022 14:14, Jan Beulich wrote:
>> On 01.03.2022 14:07, Andrew Cooper wrote:
>>> On 01/03/2022 11:05, Jan Beulich wrote:
>>> That said... what's wrong a plain NULL? I can't see any need for a
>>> magic constant here.
>> Are you fancying an XSA fo
On 01/03/2022 14:39, Andrew Cooper wrote:
> On 01/03/2022 14:14, Jan Beulich wrote:
>> On 01.03.2022 14:07, Andrew Cooper wrote:
>>> On 01/03/2022 11:05, Jan Beulich wrote:
>>> That said... what's wrong a plain NULL? I can't see any need for a
>>> magic constant here.
>> Are you fancying an XSA fo
On 01/03/2022 14:14, Jan Beulich wrote:
> On 01.03.2022 14:07, Andrew Cooper wrote:
>> On 01/03/2022 11:05, Jan Beulich wrote:
>> That said... what's wrong a plain NULL? I can't see any need for a
>> magic constant here.
> Are you fancying an XSA for a call through NULL in PV guest context?
Why d
On 01.03.2022 14:07, Andrew Cooper wrote:
> On 01/03/2022 11:05, Jan Beulich wrote:
>> Go a step further than bed9ae54df44 ("x86/time: switch platform timer
>> hooks to altcall") did and eliminate the "real" read_tsc() altogether:
>> It's not used except in pointer comparisons, and hence it looks o
On 01/03/2022 11:05, Jan Beulich wrote:
> Go a step further than bed9ae54df44 ("x86/time: switch platform timer
> hooks to altcall") did and eliminate the "real" read_tsc() altogether:
> It's not used except in pointer comparisons, and hence it looks overall
> more safe to simply poison plt_tsc's r
Go a step further than bed9ae54df44 ("x86/time: switch platform timer
hooks to altcall") did and eliminate the "real" read_tsc() altogether:
It's not used except in pointer comparisons, and hence it looks overall
more safe to simply poison plt_tsc's read_counter hook.
Signed-off-by: Jan Beulich
-
