Messages in this thread | | | Date | Mon, 5 Jun 2023 09:55:40 -0700 | Subject | Re: [PATCH v8 29/33] x86/fred: allow FRED systems to use interrupt vectors 0x10-0x1f | From | "H. Peter Anvin" <> |
| |
On 6/5/23 07:06, Thomas Gleixner wrote: > On Mon, Apr 10 2023 at 01:14, Xin Li wrote: >> From: "H. Peter Anvin (Intel)" <hpa@zytor.com> >> >> FRED inherits the Intel VT-x enhancement of classified events with >> a two-level event dispatch logic. The first-level dispatch is on >> the event type, and the second-level is on the event vector. This >> also means that vectors in different event types are orthogonal, >> thus, vectors 0x10-0x1f become available as hardware interrupts. >> >> Enable interrupt vectors 0x10-0x1f on FRED systems (interrupt 0x80 is >> already enabled.) Most of these changes are about removing the >> assumption that the lowest-priority vector is hard-wired to 0x20. > > I'm not really interested in this again premature optimization. > > Can we please clarify how the final result of FRED vector layout will > look like? > > I rather give up on reclaiming these 16 vectors than making _all_ system > vectors dynamically assignable to avoid an extra partitioning of the > vector space. >
So this patch was meant to go *after* the FRED patch set proper.
This patch does not change any of the system vectors except, by necessity, IRQ_MOVE_CLEANUP_VECTOR, nor does it change the way they are assigned to fixed vectors today.
It does make the lowest *non*-system vector a variable, but the system vectors are at the end.
This is something that should be commented: the setting of bits in system_vector is really misleading: those aren't "system vectors", they are the vectors reserved for hardware use. On IDT, this means vectors 0-31 because they are used for exceptions, but on FRED interrupts and exceptions are separate; however vectors 0-15 still need to be reserved because the APIC doesn't support them.
We *could* change that, but that is completely independent of this.
-hpa
| |