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

Re: [PATCH v3 for-4.21 1/9] x86/HPET: deal with unused channels


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 24 Oct 2025 14:16:53 +0200
  • 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=UOPvwqV9dU3hISjRzvK9ZM+p+yeS0VFusSe3+GvKsYo=; b=GUI3c4odnBt9sdl6JRnMoH65AGP9Ik8hcV9qD17VpmPXjG5ihIVSbQSMXU6+ot71eosivakh2U1m2K5gU1aZJze5oGiiyp4E55UQgUCHJf1I0HFlCZrymAlNNrcw8i+3C482XVhhekk87kus6q8Z8012en/tVbRzp1sG0wIGNn7RAG+Gk03UOpSHsCWLOXJjtudXT7UKpC17Plo4DLqOxcwJyt5lE7vxFHMTLcKqK6vb9/X6zOXYGj2vQJCNghWbKntuDy8IbE5FLmXyhBS5hOZdeiXCKtU+kJ4IesYnNKvId6qDzNILXEY15CSzZvurUzoEyusW9Ycx2trUQm3pkw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=t5pXUGM7ygsJmPBh4l8lTE1ojOoBdYwII9szOOmHnL23Ya0u4k0o7xGF43IQiqsFl6MXTV6OlY51NafnZr7EJUyF3inguFIDFaUJrLG1R4Fmqz7+T4YQVA4Pmr39+Bs4xFCTydWSPTTjRnStM5T1rNNQDzeQX3kNU8MHnt89GFHGQ4fzwlpWmi5GBmOcXtHOUDDL018e1DZMZKUsY+JuOfw7AxgfZUT7RvrJIgmYG7Nq5I2HyxjFkvHE58mVyo8lQHs9W35PuSp54/dtviJAyIC0Kwt3wmQkf8Kg5IvTKt+T3lwVMQms5UPAJ5U0kfIlOMMJrrbXZUEqh2H4VWu6mA==
  • 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>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
  • Delivery-date: Fri, 24 Oct 2025 12:26:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Oct 23, 2025 at 05:49:57PM +0200, Jan Beulich wrote:
> Keeping channels enabled when they're unused is only causing problems:
> Extra interrupts harm performance, and extra nested interrupts could even
> have caused worse problems. However, on all Intel hardware I looked at
> closely, a 0->1 transition of the enable bit causes an immediate IRQ.
> Hence disabling channels isn't a good idea there. Set a "long" timeout
> instead.
> 
> Along with that also "clear" the channel's "next event", for it to be
> properly written by whatever the next user is going to want (possibly
> avoiding too early an IRQ).
> 
> Further, along the same lines, don't enable channels early when starting
> up an IRQ. This doesn't need to happen earlier than from
> set_channel_irq_affinity() (once a channel goes into use the very first
> time). This eliminates a single instance of
> 
> (XEN) [VT-D]INTR-REMAP: Request device [0000:00:1f.0] fault index 0
> (XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt 
> request
> 
> during boot. (Why exactly there's only one instance, when we use multiple
> counters and hence multiple IRQs, I can't tell. My understanding would be
> that this was due to __hpet_setup_msi_irq() being called only after
> request_irq() [and hence the .startup handler], yet that should have
> affected all channels.)
> 
> Fixes: 3ba523ff957c ("CPUIDLE: enable MSI capable HPET for timer broadcast")
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Release-Acked-by: Oleksii Kurochko<oleksii.kurochko@xxxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks, Roger.



 


Rackspace

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