Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Xin Li <xin3.li@intel.com>, linux-kernel@vger.kernel.org,
        x86@kernel.org, kvm@vger.kernel.org
Cc:     mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
        hpa@zytor.com, peterz@infradead.org, andrew.cooper3@citrix.com,
        seanjc@google.com, pbonzini@redhat.com, ravi.v.shankar@intel.com,
        jiangshanlai@gmail.com, shan.kang@intel.com
Subject: Re: [PATCH v8 05/33] x86/traps: add external_interrupt() to
 dispatch external interrupts
In-Reply-To: <87ttvm6s2v.ffs@tglx>
References: <20230410081438.1750-1-xin3.li@intel.com>
 <20230410081438.1750-6-xin3.li@intel.com> <87ttvm6s2v.ffs@tglx>
Date:   Mon, 05 Jun 2023 19:52:11 +0200
Message-ID: <87wn0h4x10.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Mon, Jun 05 2023 at 13:56, Thomas Gleixner wrote:
> On Mon, Apr 10 2023 at 01:14, Xin Li wrote:
> How is this supposed to work once the vector space gets extended in a
> later version of FRED?
>
> Can we please think about this _now_ and not rewrite all of this two
> years down the road? 
>
> Even if that's not fully specified yet, here is the obvious question:
>
>  What are we going to do with the system vectors. Are they going to
>  stay just in the middle of the expanded vector space?
>
> That would be completely non-sensical as we'd end up with yet another
> segmentation of the vector space.
>
> So the obvious solution is to segment the vector space in the following
> way:
>
>   0  - 31   Exceptions/traps        - Cannot be moved
>  32         IRQ_MOVE_CLEANUP_VECTOR
>  33  - X    System vectors including APIC_SPURIOUS
>  X+1 - MAX  External interrupts
>
> This spares the IRQ_MOVE_CLEANUP_VECTOR hackery. It requires to move the
> ISA vectors, but that's not rocket science.

Which we just discussed completely away. :)

> That makes the external interrupt vector space trivially expandable, no?

So there is a theoretical problem here that device interrupts could
starve system vectors due to the priority scheme. Needs some thought.

That whole APIC priority muck is pretty useless as long as CR8 writes
are slower than sti/cli. When I tested that last (Broadwell) they were
significantly slower.

Also it's unclear how that expansion vector space is handled
vs. priorities.

Ideally event delivery would be FIFO because that's the only guarantee
for preventing starvation without having to configure priorities (which
is mostly a wrong guess anyway).

Thanks,

        tglx