[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 4/4] x86/time: use fake read_tsc()


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 4 Apr 2022 17:33:04 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YGwiCkItbxzwbnAFSPpg2Q2/IMgz71TMPlzmAfJYVrg=; b=U3G9z6PNF544djMQbsqK5tzf2J0GLdTuzuXTl88hF4bjPsOoGLJHAJQojFRCCs4GhZga4fyPtqgjO5lvbsyujQZjHkuu2yIJg/Inqfdp+9WjCTvR2ZRhMcbWNAHpUer4rg5a96hIHaA5eXY9nKvVk1gySqiLFgPDxuCCTZ5OaK2BuHB+PqZ8burVGCXhTrwGbt9ueRZbe0ewwOjw/x2+2QV0MRCbgmyTnYs97IzDF8t1g9MletzY9MC4uekY+zojzsrozJnRFL2zcpacFSfeCJodYNwld794ZiAd6ADoXi7T7wm3GwzYLK8KZ+dTH269cSDKZY29YAYaaZBWVQTlTQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=US87PWg3Bu8ynHCK6APk+QYQET6nmnRuhxNRdhXsivVyccxRg0j8m3C84oCLXL4m9LMdEf4t/O6+LKmYV8XKE8zYj22HodQB9evPI3GNGsrHg1DYkvhEVpqvZ1aI3IImJmReRbLhgwXQLtR4dzLqfC9mNnwkbtcl3o8FjA5xaYB4wmo6YqX60XEUbvPxQV1gLCXEsIGA+UxloWZY/roUiPQUXS3nHb5c+tdhx5WJWq51wjd25xz0OOkJswN2hS0K49xKMek9YsafA/daXbek3Mruey+cACNGsJ1R572ZW552YAOdsIRDi6hx6ye8IrM70HMtP2D5cWIyMkQ3KHm5Fg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 04 Apr 2022 15:33:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.04.2022 15:22, Roger Pau Monné wrote:
> On Thu, Mar 31, 2022 at 11:31:38AM +0200, 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 read_counter hook.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> I wasn't really sure whether it would be better to use simply void * for
>> the type of the expression, resulting in an undesirable data -> function
>> pointer conversion, but making it impossible to mistakenly try and call
>> the (fake) function directly.
> 
> I think it's slightly better to avoid being able to call the function,
> hence using void * would be my preference. What's wrong with the data
> -> function pointer conversion for the comparisons?

There's no data -> function pointer conversion for the comparisons; the
situation there is even less pleasant. What I referred to was actually
the initializer, where there would be a data -> function pointer
conversion if I used void *.

>> ---
>> v2: Comment wording.
>>
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -607,10 +607,12 @@ static s64 __init cf_check init_tsc(stru
>>      return ret;
>>  }
>>  
>> -static uint64_t __init cf_check read_tsc(void)
>> -{
>> -    return rdtsc_ordered();
>> -}
>> +/*
>> + * plt_tsc's read_counter hook is not (and should not be) invoked via the
>> + * struct field. To avoid carrying an unused, indirectly reachable function,
>> + * poison the field with an easily identifiable non-canonical pointer.
>> + */
>> +#define read_tsc ((uint64_t(*)(void))0x75C75C75C75C75C0ul)
> 
> Instead of naming this like a suitable function, I would rather use
> READ_TSC_PTR_POISON or some such.

I'll be happy to name it something like this; the primary thing to
settle on is the type to use.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.