linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	kernel-team@meta.com, dave.hansen@linux.intel.com,
	luto@kernel.org, peterz@infradead.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com,
	nadav.amit@gmail.com, Rik van Riel <riel@fb.com>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: Re: [RFC v2 6/9] x86/apic: Introduce Remote Action Request Operations
Date: Tue, 20 May 2025 11:16:40 +0200	[thread overview]
Message-ID: <aCxIeJZjdSEMi__f@gmail.com> (raw)
In-Reply-To: <20250520010350.1740223-7-riel@surriel.com>


* Rik van Riel <riel@surriel.com> wrote:

> diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
> index 47051871b436..c417b0015304 100644
> --- a/arch/x86/include/asm/irq_vectors.h
> +++ b/arch/x86/include/asm/irq_vectors.h
> @@ -103,6 +103,11 @@
>   */
>  #define POSTED_MSI_NOTIFICATION_VECTOR	0xeb
>  
> +/*
> + * RAR (remote action request) TLB flush
> + */
> +#define RAR_VECTOR			0xe0
> +
>  #define NR_VECTORS			 256

This subtly breaks x86 IRQ vector allocation AFAICS.

Right now device IRQ vectors are allocated from 0x81 to 
FIRST_SYSTEM_VECTOR (POSTED_MSI_NOTIFICATION_VECTOR) or 0xeb.

But RAR_VECTOR is within that range, the the IRQ allocator will overlap 
it and result in what I guess will be misbehaving RAR code and 
misbehaving device IRQ handling once it hands out 0xeb as well.

So you need to lower NR_EXTERNAL_VECTORS for there to be no overlap 
between device IRQ vectors and system IRQ vectors.

This will substantially compresses the available device vector space 
from ~108 vectors to ~95 vectors, a ~12% reduction. RAR, under the 
current device IRQ vector allocator, will effectively reduce the number 
of vectors not by 1 vector, but by 13 vectors. This should be pointed 
out in the changelog.

It probably doesn't matter much due to MSI multiplexing, but should 
nevertheless be implemented correctly and should be documented.

Thanks,

	Ingo

  reply	other threads:[~2025-05-20  9:16 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20  1:02 [RFC v2 PATCH 0/9] Intel RAR TLB invalidation Rik van Riel
2025-05-20  1:02 ` [RFC v2 1/9] x86/mm: Introduce MSR_IA32_CORE_CAPABILITIES Rik van Riel
2025-05-21 14:57   ` Dave Hansen
2025-05-22 15:10   ` Sean Christopherson
2025-05-20  1:02 ` [RFC v2 2/9] x86/mm: Introduce Remote Action Request MSRs Rik van Riel
2025-05-21 11:49   ` Borislav Petkov
2025-05-20  1:02 ` [RFC v2 3/9] x86/mm: enable BROADCAST_TLB_FLUSH on Intel, too Rik van Riel
2025-05-20  1:02 ` [RFC v2 4/9] x86/mm: Introduce X86_FEATURE_RAR Rik van Riel
2025-05-21 11:53   ` Borislav Petkov
2025-05-21 13:57     ` Rik van Riel
2025-05-21 14:53       ` Borislav Petkov
2025-05-21 16:06         ` Rik van Riel
2025-05-21 19:39           ` Borislav Petkov
2025-05-20  1:02 ` [RFC v2 5/9] x86/mm: Change cpa_flush() to call flush_kernel_range() directly Rik van Riel
2025-05-21 11:54   ` Borislav Petkov
2025-05-21 15:16   ` Dave Hansen
2025-05-20  1:02 ` [RFC v2 6/9] x86/apic: Introduce Remote Action Request Operations Rik van Riel
2025-05-20  9:16   ` Ingo Molnar [this message]
2025-06-04  0:11     ` Rik van Riel
2025-05-21 15:28   ` Dave Hansen
2025-05-21 15:59     ` Rik van Riel
2025-05-20  1:02 ` [RFC v2 7/9] x86/mm: Introduce Remote Action Request Rik van Riel
2025-05-20  9:28   ` Ingo Molnar
2025-05-20 12:57     ` Rik van Riel
2025-05-24  9:22       ` Ingo Molnar
2025-05-20 11:29   ` Nadav Amit
2025-05-20 13:00     ` Rik van Riel
2025-05-20 20:26       ` Nadav Amit
2025-05-20 20:31         ` Rik van Riel
2025-05-21 16:38   ` Dave Hansen
2025-05-21 19:06     ` Thomas Gleixner
2025-06-03 20:08     ` Rik van Riel
2025-05-20  1:02 ` [RFC v2 8/9] x86/mm: use RAR for kernel TLB flushes Rik van Riel
2025-05-20  1:02 ` [RFC v2 9/9] x86/mm: userspace & pageout flushing using Intel RAR Rik van Riel
2025-05-20  2:48   ` [RFC v2.1 " Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aCxIeJZjdSEMi__f@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=peterz@infradead.org \
    --cc=riel@fb.com \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).