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

Re: [PATCH] x86/time: minor adjustments to init_pit()


  • To: Andrew Cooper <amc96@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 21 Jan 2022 08:44:31 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=fxBvNDGH7l8iGz2bA1ARindmiN4N+ymJwjANa0sRoKU=; b=Xlg97ob3gWWgFP+zPh+yaSTQsk+0Krm5Dt5jkujzr7HmG8qfnhYoOMf6Z6V43OGqrjjg476inEljb2q+CtgAZAMpm8Jpb7htJ758ka1gHErS9vQTIhN0hlKtbTzvm8DVYyxZ8V69wiSzCBqZKVbswYqtCeMpxXrfareg84LWFVETH4SBQltp1qIitffC7yOsBoAoC4rjK8PYBLHeWyPes9RLJ7+vWWY50TK3tBOWY6PXwx/QNKhiVp4c/NOL/lHVhJQ6WgqmfGqmpQfTbM0WWfdjZSUmkhxSQDGiCvAaI5I6/nzmytpvhlqbnkM3iT/St3Fr8vehsOptZ1CzRybFUg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CE+W6eQwQp3DC4zPQ/cq3kLPJsyvDKhgBKmrUJJl9HIS8qhGClflTCo7V4BY44PvVEj77POfeD8L2mOTij/XRKISdhubaziIXbAVk/h+ZnSWBxZsIQt4vzIHKZ7ajVOxOcRU0/hZ/PQhKUq0346bUUy97PAnDnXKj1mP5NPEZMNcX9PbamsyJpfdz4ZAt+XNcMv1oZc3UDZzfYyTIC3TJldDuypyKBwgKal3q7fUbReYIg/lqSDvw18VQyFpcLuHs2w4Rpk3lT2E2kbmnoh32YsTsZmCokbNI886I9naE70+6J96FB52wp8Xo/W3w5Jyxz+Zq95mYgIPaoxFfoFg1Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 21 Jan 2022 07:44:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 20.01.2022 17:17, Andrew Cooper wrote:
> On 17/01/2022 10:36, Jan Beulich wrote:
>> For one, "using_pit" shouldn't be set ahead of the function's last
>> (for now: only) error path. Otherwise "clocksource=pit" on the command
>> line can lead to misbehavior when actually taking that error path.
>>
>> And then make an implicit assumption explicit: CALIBRATE_FRAC cannot,
>> for example, simply be changed to 10. The way init_pit() works, the
>> upper bound on the calibration period is about 54ms.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks.

>> ---
>> Really I've noticed this while considering what would happen if someone
>> specified  "clocksource=pit" on the shim's command line. Unlike "hpet"
>> and "acpi", "pit" presently wouldn't be (explicitly) ignored. While,
>> aiui, right now the only error path would be taken (due to port 0x61
>> reads being supposed to get back 0xff), I don't think we can build on
>> that longer term: Seeing what we use port 0x61 for in traps.c, I think
>> sooner or later we will need to have some form of emulation for it. Such
>> emulation is then not unlikely to continuously report 0 in the bit in
>> question. That would leed to an infinite loop here.
> 
> If we're not already doing it, pv shim really ought to set the FADT
> hardware reduced bits.  There should be no need to depend on heuristics
> around ~0.

Before forcing this flag onto "others", I guess we'd better first
start properly honoring this mode ourselves? Outside of ACPICA code
there has been only a single use of this FADT bit so far ...

> I do suspect that the emulation for port 0x61 is obsolete enough for us
> to consider dropping.

Well, as always - I'm hesitant to drop code which we don't know for
sure cannot possibly be of use to anyone anymore, and which also isn't
known to cause (significant) harm.

Jan




 


Rackspace

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