From nobody Mon Nov 28 20:25:55 2022 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLcSC1F0kz4hq3s for ; Mon, 28 Nov 2022 20:26:19 +0000 (UTC) (envelope-from ehem@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLcSB2d2nz3HHC for ; Mon, 28 Nov 2022 20:26:18 +0000 (UTC) (envelope-from ehem@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of ehem@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=ehem@m5p.com; dmarc=none Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 2ASKPxOq044580 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 28 Nov 2022 15:26:04 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 2ASKPttl044579 for freebsd-arch@freebsd.org; Mon, 28 Nov 2022 12:25:55 -0800 (PST) (envelope-from ehem) Date: Mon, 28 Nov 2022 12:25:55 -0800 From: Elliott Mitchell To: freebsd-arch@freebsd.org Subject: Interrupts, Interrupted, Part I Message-ID: List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[m5p.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Queue-Id: 4NLcSB2d2nz3HHC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N For interrupting devices, interrupts on FreeBSD are fine. The bus interface provides a reasonable mechanism for allocating a device's interrupts. A large number of devices work fine without extensions so this appears reasonable. For interrupt controllers the situation is a horror. The x86 PIC interface has greatly evolved since the mid-1990s, but portions make it clear just how old the interface is. Interrupts on PowerPC work sufficiently differently that PowerPC has a similar, but not identical interface which doesn't share any source code with x86. When ARM was brought to FreeBSD, it had different issues with the interface. As such "INTRNG" is a third interface which shares no source code and is quite different from the other two. One of the first issues to resolve is the distinct naming of the headers. Both PowerPC and x86 have their headers as . Since INTRNG was envisioned as being platform-independent (does manage to cover both ARM and RISC-V, at least one MIPS device used it) its headers are named . This seems to mark the aspirations of the interfaces. Unfortunately this makes compatibility worse as you need a differently named header in one case. I think one of these names needs to be chosen as the standard and have everyone move to it. Being in "machine/" already marks the headers as potentially being incompatible, so I suggest is the better option. Could D35559 collect some opinions and then maybe this can progress? Even if the interrupt interfaces are rather distinct they *do* have quite a number of common points. All of them have a structure which serves to wrap the "intr_event" structure. As such I think it would be rather handy for all the interrupt interfaces to have an "interrupt_t" type. This makes common code which doesn't need to touch the internals easier. All 3 interfaces include the functionality of resolving an interrupt number to the associated structure. Yet of the 3, only x86 has the function "intr_lookup_source()" to provide that to the outside. For a machine-independent interface I'm inclined to think "intr_lookup()" is better as not all architectures refer to the structure as "source". From 9b33b154b531, the justification for having the interrupt number in the intr_event structure is to allow MI source code to lookup interrupt numbers. Problem is, this lookup is a (slow) linear search whereas 2 of 3 architecture interfaces have an efficient lookup. The third could implement hashing for efficient lookup. Worse, this interface was restricted to the event core, so it simply fails to be useful for interrupt controllers. Once there is an MI interface and MI type, this becomes simple to use the existing heavily used interface. As such there were detours, but D32504 looks like a good solution. I hope the changes make this acceptable. Yet I still need reviews and then a committer... -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445