[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 8/8] x86/HPET: don't arbitrarily cap delta in reprogram_hpet_evt_channel()
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Thu, 22 Jan 2026 11:23:43 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=XVF/8qbQOIejmy75Xasc0uICoy3EWmNEGvLlAINjnE4=; b=w3HHfhhWuIgRP4V5Zcj5eIykvNhqK23eFfbFDjcvzrRjZPiolRqdch7wJLPQ8iu1SXKrNYFiOfwlYHN5k5TK7d7Z7lFxPCoHUpbPAGlXht1uZOwjsGAMu83aNfs51FaljotXA8Aqr0vTKLl3bCgljSy6SOyD1U/xqre8nK00t5t6koVBin9H0Uz8vottJ2zpd0/DnhIwt2ZYemjOw1XeN45w/X9O27ySAFiDPnCPuBkbiohpETVsbOtSAVtUruIRrUlVlRA0el45/WIUx6gqTVfe8cUZpV1keddvljioEYw9az9jh/TUlnOsnfU2YD2zYXVjEBnfYQ66fZG03dnM1w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nmFf3n8OHQgdnRbrp6JU1Y2TCe5/TS2YyN1rmoYzhrPo7O7EynBkLmmOCenJZvjKGHewVmJg6YWD1ZHIHFLGWL+e5pLsuIgFIy5iNXwOpsOuzVMMyJr1Li4ApMT86aQ88U4m8ECMzn2tlBq7Sn57AidaSBeQELqM/Yn7w+8pNyMxlXS4CTzsHaenzTZTNiLgWhoe7NaMckKTwsU5RmJIy+JyPJR3R6iZfxjcmqyfRAcr5GHgqvZQxYkJUa/+uDHCUVgWDIK6QP1/EMl/YKIr5gujgQYWtyI4hMu8IHYJraGhqawTVZnJsNqvKcUB7zPvYac4cDW4F3C1BNsX8I2XNg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Delivery-date: Thu, 22 Jan 2026 10:24:04 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Nov 17, 2025 at 03:40:08PM +0100, Jan Beulich wrote:
> There's no reason to set an arbitrary upper bound of 10 seconds. We can
> simply set the comparator such that it'll take a whole cycle through all
> 32-bit values until the next interrupt would be raised. (For an extremely
> fast-running HPET [400 MHz and up] 10 seconds would also be too long.)
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v4: New.
>
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -23,7 +23,6 @@
> #include <asm/irq-vectors.h>
> #include <asm/msi.h>
>
> -#define MAX_DELTA_NS MILLISECS(10*1000)
> #define MIN_DELTA_NS MICROSECS(20)
>
> #define HPET_EVT_USED_BIT 0
> @@ -162,10 +161,15 @@ static int reprogram_hpet_evt_channel(
>
> ch->next_event = expire;
>
> - delta = min_t(int64_t, delta, MAX_DELTA_NS);
> delta = max_t(int64_t, delta, MIN_DELTA_NS);
> delta = ns2ticks(delta, ch->shift, ch->mult);
>
> + if ( delta > UINT32_MAX )
> + {
> + hpet_write32(hpet_read32(HPET_COUNTER), HPET_Tn_CMP(ch->idx));
Should Xen disable interrupts around this call to avoid unexpected
latency between the counter read and the comparator write?
Thanks, Roger.
|
