Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111126 > unrolled thread
| Started by | Robert Finch <robfi680@gmail.com> |
|---|---|
| First post | 2025-03-13 00:50 -0400 |
| Last post | 2025-03-17 17:33 -0400 |
| Articles | 20 on this page of 211 — 12 participants |
Back to article view | Back to comp.arch
MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 00:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 16:34 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 13:49 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-13 15:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 20:46 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:39 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-13 17:00 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:27 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 19:28 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 21:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 21:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 23:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-13 23:52 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 14:52 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 15:34 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 17:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-14 18:12 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-14 18:42 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-14 22:10 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 17:46 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-15 16:46 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-15 22:28 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-16 17:35 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-16 22:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 13:38 +0000
Re: MSI interrupts Michael S <already5chosen@yahoo.com> - 2025-03-17 16:11 +0200
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 11:23 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-17 14:33 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:14 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-18 14:51 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 17:59 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 23:00 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:49 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:54 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:14 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:03 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-19 14:03 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:59 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:44 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:41 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 20:25 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 21:55 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 12:37 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 13:59 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:49 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:12 -0700
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-24 19:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:02 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:05 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:17 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:14 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:32 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 17:36 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-24 14:02 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 19:09 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:29 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:27 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:43 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 11:48 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:29 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 13:28 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 13:53 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 20:33 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:47 +0000
Re: MSI interrupts Terje Mathisen <terje.mathisen@tmsw.no> - 2025-03-27 10:55 +0100
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 20:31 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 19:08 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 11:20 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 13:38 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:21 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:23 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:29 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 16:53 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 13:46 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-24 12:09 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 20:11 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 22:50 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 23:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 01:53 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 01:26 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 00:07 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 12:23 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 13:45 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 15:01 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 15:10 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 16:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-25 20:40 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 22:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 18:49 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 23:33 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-25 22:58 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:40 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:42 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 09:17 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-27 13:42 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-25 17:09 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 01:00 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 00:56 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 04:08 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 09:55 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-26 14:57 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-26 13:22 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 22:19 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 19:21 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:41 -0400
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-26 15:50 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:16 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 21:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-26 23:22 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-26 23:48 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 00:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 12:46 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 17:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 14:27 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-27 18:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 19:18 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 01:01 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:35 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 01:47 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 22:02 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:14 -0700
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-29 10:31 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:56 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-27 21:52 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:58 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:09 -0700
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-27 19:10 -0700
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-27 21:47 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-28 02:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-28 15:24 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-28 11:41 -0400
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-28 09:51 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 14:28 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 15:23 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:58 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-29 22:04 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-25 10:54 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-25 16:31 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-25 17:44 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-28 14:40 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-29 20:55 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-30 16:34 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 03:33 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-31 01:30 -0400
Software synchronization (was: Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-31 14:42 +0000
Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-03-31 15:28 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-01 16:44 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 15:31 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 12:49 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 20:01 +0000
Re: Threads (was Re: MSI interrupts) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-01 13:17 -0700
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-01 22:04 +0000
Re: Threads (was Re: MSI interrupts) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-04-02 06:25 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-02 13:04 +0000
Re: Threads (was Re: MSI interrupts) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-04-03 16:45 +0200
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:00 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 17:16 +0000
Re: Threads (was Re: MSI interrupts) scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 17:24 +0000
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-04 01:44 +0000
Centronics (was Re: Threads (was Re: MSI interrupts)) George Neuner <gneuner2@comcast.net> - 2025-04-03 22:22 -0400
Re: Centronics (was Re: Threads (was Re: MSI interrupts)) scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 02:29 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-03 01:38 -0400
Re: Threads (was Re: MSI interrupts) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-03 12:15 +0000
Re: Threads (was Re: MSI interrupts) Robert Swindells <rjs@fdy2.co.uk> - 2025-04-04 10:41 +0000
Re: Threads (was Re: MSI interrupts) George Neuner <gneuner2@comcast.net> - 2025-04-04 23:10 -0400
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-04-01 10:07 -0400
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-04-01 17:39 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 23:28 +0000
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-20 12:50 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 22:28 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-23 12:16 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-23 16:48 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-24 11:55 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-24 18:56 +0000
Re: MSI interrupts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-23 17:48 -0700
Re: MSI interrupts cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-24 18:39 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-20 12:03 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-20 19:52 +0000
Re: MSI interrupts EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-19 13:07 -0400
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 15:47 -0400
Re: MSI interrupts - Instructions Robert Finch <robfi680@gmail.com> - 2025-03-26 06:56 -0400
Re: MSI interrupts - Instructions EricP <ThatWouldBeTelling@thevillage.com> - 2025-03-26 10:33 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 22:49 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 20:39 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 01:22 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-18 23:22 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 13:54 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 15:56 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 21:49 +0000
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 01:34 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 18:51 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-18 19:19 +0000
Re: MSI interrupts Stefan Monnier <monnier@iro.umontreal.ca> - 2025-03-19 11:20 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 16:00 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-19 13:27 -0400
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-19 19:17 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 10:12 -0400
Re: MSI interrupts scott@slp53.sl.home (Scott Lurndal) - 2025-03-17 15:53 +0000
Re: MSI interrupts mitchalsup@aol.com (MitchAlsup1) - 2025-03-17 19:06 +0000
Re: MSI interrupts Robert Finch <robfi680@gmail.com> - 2025-03-17 17:33 -0400
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-20 22:28 +0000 |
| Message-ID | <536efe4d9fd254ac1dfd37f9d9a43838@www.novabbs.org> |
| In reply to | #111240 |
On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: > In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, > MitchAlsup1 <mitchalsup@aol.com> wrote: > > But let me turn it around, what real-world problem does this > interrupt prioritization scheme solve coupled with the inability > to disable interrupts solve? The OS does not have to "walk" its schedule queues in order to context switch. The SVR (SuperVisor Return) instruction checks the priority of the thread that had been interrupted, and if it is of lower priority than what is pending in the interrupt table, the one on the interrupt table receives control while the lower priority thread remains interrupted. Thus, the return path from an ISR, just does an SVR. If a DPC/softIRQ has been setup, or another interrupt has become pending, HW chooses the path--acting as if HW returned control to the interrupted thread, and then immediately took the inter- rupt of highest priority still pending--without having executed a single instruction in the interrupted thread. > Is anyone complaining that the > ability to disable interrupts is somehow a serious burden? This thread started with the notion of MSI interrupts and the inherent need to DI upon arrival at ISR dispatcher. This sub- thread is investigating whether one can perform ISRs without disabling interrupts. Thus, making IDisablement an unnecessary part of interrupt servicing itself. Your (and EricP)'s contribution is to annotate those instances where one can arrive at an ISR IE and still want/need to DI and EI independent of the control transfer from and back to interrupted thread (even if control arrives reentrantly from interrupted thread). Many computer designers copy/modify their interrupt architectures from machines architected prior to the virtualization of Operating Systems, virtualization of interrupts, HyperVisors, Paranoid threads (like banking applications) that have survived into the present. I went the other way, trying to develop a system whereby the path across context switching domains is cheap and easy*. Not needing to DI at entry to ISR or exception handlers (more or less) fell out for free due to the way "the rest of the system" evolved. (*) cheap for HW, and easy expressly for SW Not being employed, and not having an OS guy to bounce ideas off and discuss consequences of going this way or that way is not available, so I lean on a few people hear to "beat me up" when my ideas lead me astray. 18 months ago I had a real-time version of the architecture, with the property that at any instant in time, each core was executing the highest priority thread, cores had a means to message back and forth as if it were a remote procedure call which could return (synchronous; or not--asynchronous) without an OS mediating these things. I abandoned it not because it was not good for real time, but because there was no way to make it Linux Friendly. Where I am now, is my attempt at being Linux friendly. > > - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-23 12:16 -0400 |
| Message-ID | <utWDP.1370783$TBhc.860098@fx16.iad> |
| In reply to | #111246 |
MitchAlsup1 wrote: > On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: > >> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >> >> But let me turn it around, what real-world problem does this >> interrupt prioritization scheme solve coupled with the inability >> to disable interrupts solve? > > The OS does not have to "walk" its schedule queues in order to > context switch. > > The SVR (SuperVisor Return) instruction checks the priority of > the thread that had been interrupted, and if it is of lower > priority than what is pending in the interrupt table, the > one on the interrupt table receives control while the lower > priority thread remains interrupted. > > Thus, the return path from an ISR, just does an SVR. If a > DPC/softIRQ has been setup, or another interrupt has become > pending, HW chooses the path--acting as if HW returned control > to the interrupted thread, and then immediately took the inter- > rupt of highest priority still pending--without having executed > a single instruction in the interrupted thread. > >> Is anyone complaining that the >> ability to disable interrupts is somehow a serious burden? > > This thread started with the notion of MSI interrupts and the > inherent need to DI upon arrival at ISR dispatcher. This sub- > thread is investigating whether one can perform ISRs without > disabling interrupts. Thus, making IDisablement an unnecessary > part of interrupt servicing itself. > > Your (and EricP)'s contribution is to annotate those instances > where one can arrive at an ISR IE and still want/need to DI and EI > independent of the control transfer from and back to interrupted > thread (even if control arrives reentrantly from interrupted thread). Supervisor return, whatever it is called - sysret, rei, svr - is traditionally another point where a number of OS race conditions can force it to briefly disable interrupts. The classic case is when a DPC/SoftIrq may be posted by an Interrupt Service Routine (ISR) and causes the First Level Interrupt Handler (FLIH), which is the ISR nested first on the stack of priority interrupts, to exit into the OS rather than return to its prior thread. The race condition occurs between the point when the FLIH ISR epilogue checks for pending a pending DPC, and not finding one decides to return to the prior thread. Between that check and the SVR instruction a higher priority interrupt occurs and posts a DPC. Another race condition can be how does an epilogue know if it is a FLIH or nested one? A counter for each core incremented by the ISR prologue and checked by the epilogue would do but what if the nested interrupt catches a lower level prologue just before it increments the counter. There are a number of non-interruptible checks and control flag changes that supervisor return must perform. To do this I have a single instruction CSVR Conditional Supervisor Return which handles all interrupt, exception, and SysCall returns. It performs a model specific test on an interrupt control register and if True changes the ICR state and returns to the prior context. If False makes other ICR state changes and falls through the CSVR instruction where code can determine what just changed. This would typically be a jump into the OS Dispatcher to flush any DPC/SoftIrq and check for thread rescheduling. This whole return sequence is performed without having to disable interrupts.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-23 16:48 +0000 |
| Message-ID | <7ad38759ddce1009c63ed19f26e7763f@www.novabbs.org> |
| In reply to | #111253 |
On Sun, 23 Mar 2025 16:16:16 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: >> >>> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> >>> But let me turn it around, what real-world problem does this >>> interrupt prioritization scheme solve coupled with the inability >>> to disable interrupts solve? >> >> The OS does not have to "walk" its schedule queues in order to >> context switch. >> >> The SVR (SuperVisor Return) instruction checks the priority of >> the thread that had been interrupted, and if it is of lower >> priority than what is pending in the interrupt table, the >> one on the interrupt table receives control while the lower >> priority thread remains interrupted. >> >> Thus, the return path from an ISR, just does an SVR. If a >> DPC/softIRQ has been setup, or another interrupt has become >> pending, HW chooses the path--acting as if HW returned control >> to the interrupted thread, and then immediately took the inter- >> rupt of highest priority still pending--without having executed >> a single instruction in the interrupted thread. >> >>> Is anyone complaining that the >>> ability to disable interrupts is somehow a serious burden? >> >> This thread started with the notion of MSI interrupts and the >> inherent need to DI upon arrival at ISR dispatcher. This sub- >> thread is investigating whether one can perform ISRs without >> disabling interrupts. Thus, making IDisablement an unnecessary >> part of interrupt servicing itself. >> >> Your (and EricP)'s contribution is to annotate those instances >> where one can arrive at an ISR IE and still want/need to DI and EI >> independent of the control transfer from and back to interrupted >> thread (even if control arrives reentrantly from interrupted thread). > > Supervisor return, whatever it is called - sysret, rei, svr - > is traditionally another point where a number of OS race conditions > can force it to briefly disable interrupts. > > The classic case is when a DPC/SoftIrq may be posted by an Interrupt > Service Routine (ISR) and causes the First Level Interrupt Handler > (FLIH), > which is the ISR nested first on the stack of priority interrupts, > to exit into the OS rather than return to its prior thread. > > The race condition occurs between the point when the FLIH ISR epilogue > checks for pending a pending DPC, and not finding one decides to return > to the prior thread. Between that check and the SVR instruction a higher > priority interrupt occurs and posts a DPC. I remove that race condition by removing the need for FLIR (which I call the dispatcher) to check. All the checks are done AT* the SVR instruction. (*) and during > Another race condition can be how does an epilogue know if it is a FLIH > or nested one? A counter for each core incremented by the ISR prologue > and checked by the epilogue would do but what if the nested interrupt > catches a lower level prologue just before it increments the counter. How to know:: It COULD look at the value in its stack pointer. An empty stack implies it is leaving, a non-empty stack implies it has more to do. But in practice, it does not need to know as interrupts are properly nested and serviced in priority order. > There are a number of non-interruptible checks and control flag changes > that supervisor return must perform. > > To do this I have a single instruction CSVR Conditional Supervisor > Return > which handles all interrupt, exception, and SysCall returns. It performs > a model specific test on an interrupt control register and if True > changes > the ICR state and returns to the prior context. If False makes other ICR > state changes and falls through the CSVR instruction where code can > determine what just changed. This would typically be a jump into the OS > Dispatcher to flush any DPC/SoftIrq and check for thread rescheduling. > This whole return sequence is performed without having to disable > interrupts. I, too, have a single instruction (SVR) that delivers control to the highest priority still pending thread, regardless of whether it is a new interrupt, a scheduled DPC/softIRQ, a local timer, an IPI, or the thread the interrupt stack was placed upon. SVR looks at the priority of the thread to receive control, and the priorities of pending 'interrupts' (of which DPC/softIRQ and IPIs are part) and transfers control to the highest priority pending thread--occasionally that thread is the interrupted one. Should a higher priority thread become pending while SVR is in progress, the higher priority thread will receive control before the first inst- ruction of the mis-receiving thread is performed. As far as you have explained these things to me, I see no race conditions in the architected means.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-24 11:55 -0400 |
| Message-ID | <jhfEP.414301$3pn5.20553@fx44.iad> |
| In reply to | #111254 |
MitchAlsup1 wrote: > On Sun, 23 Mar 2025 16:16:16 +0000, EricP wrote: > >> MitchAlsup1 wrote: >>> On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: >>> >>>> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >>>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>>> >>>> But let me turn it around, what real-world problem does this >>>> interrupt prioritization scheme solve coupled with the inability >>>> to disable interrupts solve? >>> >>> The OS does not have to "walk" its schedule queues in order to >>> context switch. >>> >>> The SVR (SuperVisor Return) instruction checks the priority of >>> the thread that had been interrupted, and if it is of lower >>> priority than what is pending in the interrupt table, the >>> one on the interrupt table receives control while the lower >>> priority thread remains interrupted. >>> >>> Thus, the return path from an ISR, just does an SVR. If a >>> DPC/softIRQ has been setup, or another interrupt has become >>> pending, HW chooses the path--acting as if HW returned control >>> to the interrupted thread, and then immediately took the inter- >>> rupt of highest priority still pending--without having executed >>> a single instruction in the interrupted thread. >>> >>>> Is anyone complaining that the >>>> ability to disable interrupts is somehow a serious burden? >>> >>> This thread started with the notion of MSI interrupts and the >>> inherent need to DI upon arrival at ISR dispatcher. This sub- >>> thread is investigating whether one can perform ISRs without >>> disabling interrupts. Thus, making IDisablement an unnecessary >>> part of interrupt servicing itself. >>> >>> Your (and EricP)'s contribution is to annotate those instances >>> where one can arrive at an ISR IE and still want/need to DI and EI >>> independent of the control transfer from and back to interrupted >>> thread (even if control arrives reentrantly from interrupted thread). >> >> Supervisor return, whatever it is called - sysret, rei, svr - >> is traditionally another point where a number of OS race conditions >> can force it to briefly disable interrupts. >> >> The classic case is when a DPC/SoftIrq may be posted by an Interrupt >> Service Routine (ISR) and causes the First Level Interrupt Handler >> (FLIH), >> which is the ISR nested first on the stack of priority interrupts, >> to exit into the OS rather than return to its prior thread. >> >> The race condition occurs between the point when the FLIH ISR epilogue >> checks for pending a pending DPC, and not finding one decides to return >> to the prior thread. Between that check and the SVR instruction a higher >> priority interrupt occurs and posts a DPC. > > I remove that race condition by removing the need for FLIR (which I > call the dispatcher) to check. All the checks are done AT* the SVR > instruction. (*) and during Ok you have that but other platforms must deal with this in code. VAX used a real priority-1 (lowest) interrupt looped back to itself to request a software interrupt, eliminating this check. Intel APIC allows this kind of self interrupt loop back too but I don't know if any OS uses it for its internal scheduling. On platforms without something like this the OS has to deal with this race condition, which requires disabling interrupts. Also on PC's the 8259 PIC has an End Of Interrupt (EOI) race condition, and it looks like the APIC has the same one, which requires briefly disabling interrupts in the return path. >> Another race condition can be how does an epilogue know if it is a FLIH >> or nested one? A counter for each core incremented by the ISR prologue >> and checked by the epilogue would do but what if the nested interrupt >> catches a lower level prologue just before it increments the counter. > > How to know:: It COULD look at the value in its stack pointer. An > empty stack implies it is leaving, a non-empty stack implies it > has more to do. The stack pointer might be too dynamic for this. It can test the if the return RIP is in a certain range. If it is inside a prologue you know it is nested. If inside the epilogue then it might have just caught the exit race so reset the return RIP to the start of the epilogue exit sequence. By arranging for all the prologues and epilogue to be at the highest addresses then a CMP and BGEU filters out the 99.999% usual cases. But all of this adds to the return from interrupt code path length. > But in practice, it does not need to know as interrupts are properly > nested and serviced in priority order. It is not checking whether they are properly nested. Only the FLIH does the check whether to return or exit through the OS. That is to prevent Dispatcher reentrancy. And this check can be replaced by a priority-1 self interrupt capability to trap into the software interrupt dispatcher. >> There are a number of non-interruptible checks and control flag changes >> that supervisor return must perform. >> >> To do this I have a single instruction CSVR Conditional Supervisor >> Return >> which handles all interrupt, exception, and SysCall returns. It performs >> a model specific test on an interrupt control register and if True >> changes >> the ICR state and returns to the prior context. If False makes other ICR >> state changes and falls through the CSVR instruction where code can >> determine what just changed. This would typically be a jump into the OS >> Dispatcher to flush any DPC/SoftIrq and check for thread rescheduling. >> This whole return sequence is performed without having to disable >> interrupts. > > I, too, have a single instruction (SVR) that delivers control to the > highest priority still pending thread, regardless of whether it is > a new interrupt, a scheduled DPC/softIRQ, a local timer, an IPI, or > the thread the interrupt stack was placed upon. > > SVR looks at the priority of the thread to receive control, and the > priorities of pending 'interrupts' (of which DPC/softIRQ and IPIs > are part) and transfers control to the highest priority pending > thread--occasionally that thread is the interrupted one. The new idea I'm proposing is CSVR *Conditional* Supervisor Return which can fall through in the unlikely event something disturbs the non-interruptible return sequence. This can be used to optimize the return path by avoiding returning from an interrupt only to immediately take a priority-1 software interrupt. > Should a higher priority thread become pending while SVR is in progress, > the higher priority thread will receive control before the first inst- > ruction of the mis-receiving thread is performed. > > As far as you have explained these things to me, I see no race > conditions > in the architected means. Perhaps not for your approach but I'm looking at other optimizations that might introduce them. One was optimizing the common return path: Before a supervisor return starts to reload the saved register set it tests if a DPC is pending and about to generate a software interrupt, and if so jumps back into the Dispatcher. This saves reloading the registers only to immediately take another interrupt, a pipeline drain and fill, and resave the same registers. To do this optimization, before it starts to reload the registers it tests the Interrupt Control Register (ICR) to check if it is about to trigger a SWI and if so adjusts the ICR and jumps into the Dispatcher. Otherwise it restores registers and does a Conditional Supervisor Return which reperforms the same test and can fall through if the test fails. This also requires that kernel/interrupt stacks be switched a certain way, which just so happens to be the same as the x86 way. That is, hardware only switches stacks if interrupted mode is User. This leaves it up to OS software to decide which stack to use at what points inside the kernel. Also I'd save the interrupt context, the old RIP, old RSP and old interrupt status in hardware registers, not on the stack, and the interrupt vector RIP address is calculated based on the priority. This eliminates all memory access from the exception and interrupt entry and exit transition sequences, and thereby eliminates page faults and memory error possibility and cache access latency.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-24 18:56 +0000 |
| Message-ID | <d9f62ae1cec5f9b2a18ca0f4e284b2ce@www.novabbs.org> |
| In reply to | #111264 |
On Mon, 24 Mar 2025 15:55:33 +0000, EricP wrote:
> MitchAlsup1 wrote:
>> On Sun, 23 Mar 2025 16:16:16 +0000, EricP wrote:
I may come back to the snipped stuff later
>
> But all of this adds to the return from interrupt code path length.
As noted in my response to Dan C, the return from interrupt code path
length is the RET instruction from the ISR back to Dispatcher and the
SVR instruction at the Dispatcher. Is this short enough?
>------------------
>> I, too, have a single instruction (SVR) that delivers control to the
>> highest priority still pending thread, regardless of whether it is
>> a new interrupt, a scheduled DPC/softIRQ, a local timer, an IPI, or
>> the thread the interrupt stack was placed upon.
>>
>> SVR looks at the priority of the thread to receive control, and the
>> priorities of pending 'interrupts' (of which DPC/softIRQ and IPIs
>> are part) and transfers control to the highest priority pending
>> thread--occasionally that thread is the interrupted one.
>
> The new idea I'm proposing is CSVR *Conditional* Supervisor Return
> which can fall through in the unlikely event something disturbs the
> non-interruptible return sequence.
I detected that. My SVR has most of those properties (can do several
different return sequences including take the next interrupt) and does
not necessarily return whence the interrupt was taken.
> This can be used to optimize the return path by avoiding returning from
> an interrupt only to immediately take a priority-1 software interrupt.
My 66000 SVR exits a current handler, but instead of returning to the
interrupted thread, it checks for any other interrupt disturbances
and if it finds one of higher priority than the interrupted thread, it
does the higher priority one(s) first, leaving the interrupted thread
for later.
SW does not have to look. SW just has to send DPCs/softIRQs as MSI-X
messages to the interrupt table of its choice. So, setting up a DPC/
softIRQ requires storing some data in a SW controlled place and manner,
and performing a single ST to the interrupt aperture to enQueue the
message at chosen priority and privilege, to be serviced by chosen
handler.
>> Should a higher priority thread become pending while SVR is in progress,
>> the higher priority thread will receive control before the first inst-
>> ruction of the mis-receiving thread is performed.
>>
>> As far as you have explained these things to me, I see no race
>> conditions
>> in the architected means.
>
> Perhaps not for your approach but I'm looking at other optimizations
> that might introduce them. One was optimizing the common return path:
It is currently standing at 2 instructions--an RET from ISR back to its
dispatcher, followed immediately by a SVR.
> Before a supervisor return starts to reload the saved register set
> it tests if a DPC is pending and about to generate a software interrupt,
> and if so jumps back into the Dispatcher. This saves reloading the
> registers
> only to immediately take another interrupt, a pipeline drain and fill,
> and resave the same registers.
Yes, yes, my SVR does that.
> To do this optimization, before it starts to reload the registers
> it tests the Interrupt Control Register (ICR) to check if it is about to
> trigger a SWI and if so adjusts the ICR and jumps into the Dispatcher.
> Otherwise it restores registers and does a Conditional Supervisor Return
> which reperforms the same test and can fall through if the test fails.
Because I do things in HW, I can start the RF reload (bring in the 5
cache lines of the thread) and while waiting for them to arrive, look
at the pending interrupts and abandon the return, ignoring the fetched
thread state; and proceed back to the top of Dispatcher. So, if SVR
finds more stuff to do, it can continue to use the RF it has.
But, because the next interrupt may be Hyper instead of Super (or
even vice versa) architecture states that HW uses the RF of the
current privilege level. This may require doing nothing (super->super)
or swapping RF (hyper->super or super->secure, from != to)
Architecturally, HW is always using the thread-state of core SW-stack
context pointers indexed by the privilege level.
> This also requires that kernel/interrupt stacks be switched a certain
> way,
> which just so happens to be the same as the x86 way. That is, hardware
> only
> switches stacks if interrupted mode is User. This leaves it up to OS
> software to decide which stack to use at what points inside the kernel.
Does x86 HW switch stacks when going from super to hyper or hyper to
Secure ?? like it does from user to super ??
--------
My 66000 has the property that a core runs a SW stack, each element
on the stack points at thread-state. Thread-state has all the control
registers needed to run a thread and a register file for each level
on the stack.
It is possible to program the system such that a (semi-trusted) user
(no privilege) is allowed to "take" his own interrupts. When doing
so, he really wants to use his own (non-privileged) stack.
It is also possible for a single interrupt table to hold interrupts
for any privilege level at any priority.
---------
You may ask why ? One of the goals here is to take the same number of
cycles to context switch between user processes as it does to switch
between different HyperVisors. Currently these are in the 1000 cycle
range (user->user) and 10,000 range for (Guest OS[1]->Guest OS[3]).
I want both of these down in the sub-100 range close; to >20 cycles
plus memory latency.
For example, one can context switch the user process by overwriting
its core software stack CR with the new process' Thread-state pointer
(and then when SVR happens the new process runs instead of the old
process) -- context switch is essentially 1 instruction. This happens
at Guest OS, and Hypervisor levels of the SW stack, too.
Supervisory software has the same path to figure out what to do
(next) and then once decided the code-path to "make it happen"
is tiny.
> Also I'd save the interrupt context, the old RIP, old RSP and old
> interrupt
> status in hardware registers, not on the stack, and the interrupt vector
> RIP address is calculated based on the priority. This eliminates all
> memory
> access from the exception and interrupt entry and exit transition
> sequences,
> and thereby eliminates page faults and memory error possibility and
> cache access latency.
As you remain aware, all thread control registers have a known memory
address from which they are read and written, these do not go on any
stack. Along with the RF they occupy 5 sequential cache lines. HW
treats them (essentially) as a write back cache.
The only things on the supervisor stack is the original value in R0
(which I had to clobber to put the MSI-X message in. And a 2-bit
of the interrupted privilege level and a 4-bit token telling SVR
what kind of stack it is dealing with {Interrupt, exception, SVC}.)
{{Looking at this now, I could probably get rid of R0 on the stack))
One of the reasons I want HW doing these things, is HW strips off
bits SW is not supposed to be looking at. It is not clear is even
supervisory SW can be so trusted--witness we have (essentially
unprivileged) units of SW that do not even want GuetOS to look at
their data (banking applications, video, rented audio, ...). They
want GuestOS to perform the I/O but not look at any of the data.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-03-23 17:48 -0700 |
| Message-ID | <vrqa4u$3ktca$1@dont-email.me> |
| In reply to | #111253 |
On 3/23/2025 9:16 AM, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: >> >>> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> >>> But let me turn it around, what real-world problem does this >>> interrupt prioritization scheme solve coupled with the inability >>> to disable interrupts solve? >> >> The OS does not have to "walk" its schedule queues in order to >> context switch. >> >> The SVR (SuperVisor Return) instruction checks the priority of >> the thread that had been interrupted, and if it is of lower >> priority than what is pending in the interrupt table, the >> one on the interrupt table receives control while the lower >> priority thread remains interrupted. >> >> Thus, the return path from an ISR, just does an SVR. If a >> DPC/softIRQ has been setup, or another interrupt has become >> pending, HW chooses the path--acting as if HW returned control >> to the interrupted thread, and then immediately took the inter- >> rupt of highest priority still pending--without having executed >> a single instruction in the interrupted thread. >> >>> Is anyone complaining that the >>> ability to disable interrupts is somehow a serious burden? >> >> This thread started with the notion of MSI interrupts and the >> inherent need to DI upon arrival at ISR dispatcher. This sub- >> thread is investigating whether one can perform ISRs without >> disabling interrupts. Thus, making IDisablement an unnecessary >> part of interrupt servicing itself. >> >> Your (and EricP)'s contribution is to annotate those instances >> where one can arrive at an ISR IE and still want/need to DI and EI >> independent of the control transfer from and back to interrupted >> thread (even if control arrives reentrantly from interrupted thread). > > Supervisor return, whatever it is called - sysret, rei, svr - > is traditionally another point where a number of OS race conditions > can force it to briefly disable interrupts. > > The classic case is when a DPC/SoftIrq may be posted by an Interrupt > Service Routine (ISR) and causes the First Level Interrupt Handler (FLIH), > which is the ISR nested first on the stack of priority interrupts, > to exit into the OS rather than return to its prior thread. > > The race condition occurs between the point when the FLIH ISR epilogue > checks for pending a pending DPC, and not finding one decides to return > to the prior thread. Between that check and the SVR instruction a higher > priority interrupt occurs and posts a DPC. > > Another race condition can be how does an epilogue know if it is a FLIH > or nested one? A counter for each core incremented by the ISR prologue > and checked by the epilogue would do but what if the nested interrupt > catches a lower level prologue just before it increments the counter. [...] Fun with race conditions... check out some of this shit: https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ ;^D
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2025-03-24 18:39 +0000 |
| Message-ID | <vrs8st$pnb$1@reader1.panix.com> |
| In reply to | #111246 |
In article <536efe4d9fd254ac1dfd37f9d9a43838@www.novabbs.org>, MitchAlsup1 <mitchalsup@aol.com> wrote: >On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: > >> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >> MitchAlsup1 <mitchalsup@aol.com> wrote: >> >> But let me turn it around, what real-world problem does this >> interrupt prioritization scheme solve coupled with the inability >> to disable interrupts solve? > >The OS does not have to "walk" its schedule queues in order to >context switch. Of course it does. The OS is the entity that selects the next thing to run and assigns priorities. Even in a scheme where the hardware has a notion of priority that the operating system can rely on directly, priorities can change over time and the OS has to be able to account for that. >The SVR (SuperVisor Return) instruction checks the priority of >the thread that had been interrupted, and if it is of lower >priority than what is pending in the interrupt table, the >one on the interrupt table receives control while the lower >priority thread remains interrupted. First, this sounds completely non-portable. Second, how does one handle scheduling policies around threads that are all at the same priority level? Third, as an OS person, this is a pet peeve of mine, from both hardware and language perspectives: how does the hardware guarantee that it's notion of a "thread" is the same as mine? I don't like it when systems force a particular "shape" of a solution on me. POSIX threads in hardware is something that I explicitly do not want, because any impedence mismatch between the hardware idea and what I need in the OS create friction, and limits my ability to build the system that I want. >Thus, the return path from an ISR, just does an SVR. If a >DPC/softIRQ has been setup, or another interrupt has become >pending, HW chooses the path--acting as if HW returned control >to the interrupted thread, and then immediately took the inter- >rupt of highest priority still pending--without having executed >a single instruction in the interrupted thread. See above. As an OS person, I find this level of intimacy with the hardware horrifying. It reminds me of the VAX queue instructions; neat idea, VMS used them, but awful in practice and Unix largely ignored them. As a result, it made VMS harder to port than was necessary. >> Is anyone complaining that the >> ability to disable interrupts is somehow a serious burden? > >This thread started with the notion of MSI interrupts and the >inherent need to DI upon arrival at ISR dispatcher. This sub- >thread is investigating whether one can perform ISRs without >disabling interrupts. Thus, making IDisablement an unnecessary >part of interrupt servicing itself. Yes, but why? I can see some neat symmetry with, say, replacing NMIs with "infinite priority" interrupts, and perhaps using an interrupt priority mask to de facto disable interrupt delivery at the local core; maybe that's useful internally. But I'm not seeing the use case beyond that. >Your (and EricP)'s contribution is to annotate those instances >where one can arrive at an ISR IE and still want/need to DI and EI >independent of the control transfer from and back to interrupted >thread (even if control arrives reentrantly from interrupted thread). > >Many computer designers copy/modify their interrupt architectures >from machines architected prior to the virtualization of Operating >Systems, virtualization of interrupts, HyperVisors, Paranoid threads >(like banking applications) that have survived into the present. > >I went the other way, trying to develop a system whereby the path >across context switching domains is cheap and easy*. Not needing >to DI at entry to ISR or exception handlers (more or less) fell >out for free due to the way "the rest of the system" evolved. > >(*) cheap for HW, and easy expressly for SW > >Not being employed, and not having an OS guy to bounce ideas off >and discuss consequences of going this way or that way is not >available, so I lean on a few people hear to "beat me up" when >my ideas lead me astray. > >18 months ago I had a real-time version of the architecture, >with the property that at any instant in time, each core was >executing the highest priority thread, cores had a means to >message back and forth as if it were a remote procedure call >which could return (synchronous; or not--asynchronous) without >an OS mediating these things. I abandoned it not because it >was not good for real time, but because there was no way to >make it Linux Friendly. > >Where I am now, is my attempt at being Linux friendly. This sounds like it may be interesting for a hard real-time controller type application with a very thin RTOS, but it's not all that useful for a general-purpose system. Here's the problem, though. Being "Linux friendly" is going to impose design constraints on you that will force you in the direction of producing an architecture that is far more conventional than what you are proposing above. If that's what you want, that's totally fine of course; but if you want to experiment with a substantially different system architecture, you're not going to accept that you're software story is going to be largely bespoke and unportable. That's not to say your _userspace_ story has to be like that, but your OS will. Moreover, there's the issue of, how do you expose these primitives through a high-level language? Most programmers are not going to be willing to drop down to assembler for these atomic sequences; maybe to build a mutex primitive or something, but not for much larger things. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-20 12:03 -0400 |
| Message-ID | <l%WCP.2$D41.1@fx45.iad> |
| In reply to | #111238 |
MitchAlsup1 wrote:
> On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote:
>
>> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>,
>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>> I want to address the elephant in the room::
>>>
>>> Why disable interrupts AT ALL !!
>>
>> So that you can have some mechanism for building critical
>> sections that span multiple instructions, where just having
>> access to atomics and spin locks isn't enough.
>
> For what kinds of activities are these critical sections ??
>
> For example, I can schedule a DPC/sofIRQ without using a critical
> section (and so can even user threads without privilege, given
> the MMU allows). So, we need to dive through the "rest of the
> available mechanics" -- keyword available !
>
> There are mechanisms available that readers may not be aware of
> or quite grasp how a feature can be used.
>
> So it comes back to:: For what kinds of activities are these
> critical sections ?? We know about DPC/softIRQs, we know
> about atomic events around core scheduling, and inter-{thread,
> process, core} communication. Others ?
>
>>> When running at any privilege, do you not want to accept an interrupt
>>> at higher priority with as little delay as possible ??
>>
>> Usually the assumption is that the critical section is short; a
>> handful of instructions, perhaps, so that the cost of blocking a
>> high priority interrupt is low.
>
> I think you are talking about critical sections that are not allowed
> to fail or be interfered with:: Yes ?
There are various situations.
1) There are single memory locations used by the OS for communicating
between interrupt priority levels with a single core
that must be updated with an non interruptible R-M-W sequence.
2) Rarely in a OS there may be multiple memory locations for communicating
between interrupt priority levels within a single core
that must be updated with an non interruptible R-M-W sequence.
3) Sometimes devices are (mis)designed such that multiple control
registers must be written in a non-interruptible manner.
For handling #1 I have a set of non-interruptible RMW instructions.
These are the same as their atomic RMW cousins except without fences
because they are only used for communication within a single core.
These take care of the vast majority of intra-core inter-level signaling:
ninswp Non-interruptible swap
nincas Non-interruptible compare and swap
ninfadd Non-interruptible fetch ADD
ninfand Non-interruptible fetch AND
ninfor Non-interruptible fetch OR
ninfxor Non-interruptible fetch XOR
For situations 2 & 3 there really is no alternative but to shut off
all interrupts for a few instructions.
For example, there were two 8259 Interrupt Controllers in the PC that
in order to do a return from interrupt had to be manipulated in a
non-interruptible sequence. So you had to shut off all interrupts,
write two 8259 control registers, then REI which re-enabled interrupts.
People design devices where you write control register A with the
number of a register that will be written when you write register B.
I don't know why people keep doing this, but they do.
If those registers A and B are written by multiple interrupt levels
then that is a non-interruptible sequence and forces you disable all
interrupts for that two write sequence.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-20 19:52 +0000 |
| Message-ID | <6eb6004962d746cc1fb0fb84df07dff5@www.novabbs.org> |
| In reply to | #111241 |
Thank you EricP for that list of uses strenuously wanting interrupts to be disabled.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-19 13:07 -0400 |
| Message-ID | <ZRCCP.595878$BrX.126145@fx12.iad> |
| In reply to | #111218 |
Robert Finch wrote: > > I am going for a simple approach. Since the CSR instruction is used to > manipulate the interrupt enable bits in the status register, if there is > any CSR instruction in the pipeline, then interrupts will be masked off > until the CSR clears. One issue with this type of approach is evil > software could issue a lot of CSRs preventing interrupt servicing from > happening. I Could fine tune the decode to sort out CSRs just affecting > the interrupt flags. It always seems to be more logic. KISS is usually best - just single step the major actions. I added single step to my uArch with a NotifyDecode flag in the uOp. To single step Decode emits a special nop uOp with a NotifyDecode bit and sets a Stop flip-flop that stalls Decode. The Fetch buffer fills up and Fetch stalls itself. When the special nop reaches Retire we know all older instructions are done. Retire sees the NotifyDecode bit and pulses a wire that clears the Decode Stop FF. Decode then emits the single step instruction uOp again with the NotifyDecode bit and sets its Stop FF. When that uOp reaches Retire it pulses the wire and clears the Decode Stop flag, which reads the Fetch buffer and restarts the front end.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-19 15:47 -0400 |
| Message-ID | <vrf712$1h233$1@dont-email.me> |
| In reply to | #111233 |
On 2025-03-19 1:07 p.m., EricP wrote: > Robert Finch wrote: >> >> I am going for a simple approach. Since the CSR instruction is used to >> manipulate the interrupt enable bits in the status register, if there >> is any CSR instruction in the pipeline, then interrupts will be masked >> off until the CSR clears. One issue with this type of approach is evil >> software could issue a lot of CSRs preventing interrupt servicing from >> happening. I Could fine tune the decode to sort out CSRs just >> affecting the interrupt flags. It always seems to be more logic. > > KISS is usually best - just single step the major actions. > > I added single step to my uArch with a NotifyDecode flag in the uOp. > To single step Decode emits a special nop uOp with a NotifyDecode bit > and sets a Stop flip-flop that stalls Decode. The Fetch buffer fills up > and Fetch stalls itself. When the special nop reaches Retire we know all > older instructions are done. Retire sees the NotifyDecode bit and pulses > a wire that clears the Decode Stop FF. > > Decode then emits the single step instruction uOp again with the > NotifyDecode bit and sets its Stop FF. When that uOp reaches Retire > it pulses the wire and clears the Decode Stop flag, which reads the > Fetch buffer and restarts the front end. > > Crafty. I have not implemented single-step yet; there is a bit in the status register for this, but I have been debugging with the CPU operating in SERIALIZE mode, which executes instructions one-at-a-time. Instead of stalling the pipeline, in the scheduler it checks if the previous instruction is done yet, if it is not done, then the next instruction does not issue. So SERIALIZE operates the pipeline in a one-way fashion. The done check is done with a parameter, so it does cause code to be modified. I suppose this could be made another status register option. Found a lot of bugs using SERIALIZE, but maybe time to add single-stepping.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-26 06:56 -0400 |
| Subject | Re: MSI interrupts - Instructions |
| Message-ID | <vs0mg1$1jef9$1@dont-email.me> |
| In reply to | #111237 |
Working on a simple OS I thought it might be useful to be able to poll for interrupts when interrupts are disabled. I think there may be times where it is acceptable to process certain kinds of interrupts even if they were disable. So, I added a poll-for-interrupt instruction to the architecture. Which just checks for interrupts and continues if there is not one. I have seen wait-for-interrupt instructions before, but not sure about polling. I also added a two-up-level return from interrupt instruction. I have not seen this in other architectures, but I needed it at one point. Interrupt information is stored on an internal stack, and it is tricky (slow) to manipulate it for a two-up-level return. It is an eight level stack with two or three words of information per level. It was a bit much to copy it all in software, so I added the hardware return. But it is a lot of extra hardware for a very rare occurrence. Finding this discussion on interrupts informative. I have only done a modicum of work on an OS; tried to get things working with spinlocks.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-03-26 10:33 -0400 |
| Subject | Re: MSI interrupts - Instructions |
| Message-ID | <LfUEP.943025$BrX.619650@fx12.iad> |
| In reply to | #111327 |
Robert Finch wrote: > Working on a simple OS I thought it might be useful to be able to poll > for interrupts when interrupts are disabled. I think there may be times > where it is acceptable to process certain kinds of interrupts even if > they were disable. So, I added a poll-for-interrupt instruction to the > architecture. Which just checks for interrupts and continues if there is > not one. I have seen wait-for-interrupt instructions before, but not > sure about polling. > > I also added a two-up-level return from interrupt instruction. I have > not seen this in other architectures, but I needed it at one point. > Interrupt information is stored on an internal stack, and it is tricky > (slow) to manipulate it for a two-up-level return. It is an eight level > stack with two or three words of information per level. It was a bit > much to copy it all in software, so I added the hardware return. But it > is a lot of extra hardware for a very rare occurrence. > > Finding this discussion on interrupts informative. I have only done a > modicum of work on an OS; tried to get things working with spinlocks. I'm not sure what your "polling for interrupts" would do. That's what the cpu already does - in the background at the start of each instruction the cpu polls for interrupts. Most cpu's have a "wait for interrupt" or "halt" instruction which stops fetching and sits waiting for an interrupt to be injected. It is typically used when the OS has no work to do and doesn't want to sit in a spin-loop burning calories. So it goes into a lower power state waiting for a wakeup event. There is an optimization that has been around a while where a driver shuts off interrupts from a particular device and switches to polling that one device, removing the interrupt setup and delivery overhead, making that time available for doing work. But that is driver specific. DEC had a paper on this for a TCP/IP driver. Eliminating Receive Livelock in an Interrupt-driven Kernel, 1995 http://bitsavers.trailing-edge.com/pdf/dec/tech_reports/WRL-95-8.pdf The idea is that polling is more expensive when request rate is low, and interrupts are more expensive when request rate is high. We can dynamically adapt to optimize between the two, making that time available for making forward progress. But this interrupt masking is at the device level and has nothing to do with the cpu interrupt mechanism.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-18 22:49 +0000 |
| Message-ID | <1a57cd46e8a99a827a10e55e18d3ca07@www.novabbs.org> |
| In reply to | #111215 |
On Tue, 18 Mar 2025 18:51:57 +0000, EricP wrote:
> Robert Finch wrote:
>> On 2025-03-17 2:33 p.m., EricP wrote:
----------------
>>> This also raises a question about what the ICU is doing during this
>>> long latency handoff. One wouldn't want ICU to sit idle so it might
>>> have to manage the handoff of multiple interrupts to multiple cores
>>> at the same time, each as its own little state machine.
>>>
>>> One should see that this decision on how the core handles the
>>> handoff has a large impact on the design complexity of the ICU.
>>>
>>> Personally, I would use method 1 first to get something working
>>> then if this is OoO think about getting fancy with method 2.
>>>
>>>
>> Would it not be rare for this to occur? If so, I think the pipeline
>> could just be flushed from the int disabling instruction on. Then the
>> interrupted address recorded as the int disabling instruction. <- this
>> requires identification of an int disabling instruction though. It might
>> just be a store to a specific I/O address, therefore a special store
>> opcode to make it easy to detect?
>
> It likely is rare but the possibility that the existing instructions,
Which is rare:
executing 200 instructions without an exception ?
OR
executing 200 instructions without a mispredict ?
The former is fairly rare, the later is not so rare.
> a branch mispredict or an exception throw, could retroactively change
> the state of the interrupt enable flag to disabled creates this
> Window of Uncertainty (WoU) that is the length of the pipeline.
All the more reasons that the very vast majority of interrupts and
exceptions do not have to disable more of their kind or their
opposite.
In My 66000 interrupt architecture, the very first instruction in the
interrupt dispatcher can take a higher priority interrupt-----the
page fault handler in Guest OS can take a page fault in HyperVisor
MMU tables, without any special precautions or code sequences.
> Unless one can find a way to make WoU go away the ICU needs to deal
> with the possibility that there could be hundreds of clocks between
> when ICU asks a core if it can accept an interrupt and when the core
> does.
The window will always exist--so, the best one can do is eliminate
the core's sensitivity to the WoU.
> I had a few ideas walking in the park yesterday. I had been assuming
> that
> when an exception is delivered that it would also automatically disable
> interrupts. That may not be a good idea as it means that any instruction
> that can throw an exception could cause this retroactive disabling.
My 66000 simply defines that this cannot happen::
Exceptions do not alter the behavior of interrupts;
Interrupts do not alter the behavior of exceptions.
> If I remove that exception side effect then the only things that can
> manipulate the core's master Interrupt Enable flag are the enable INTEN
> and disable INTDI instructions, and the actual delivery of an interrupt.
Let's postulate we have a core running at low priority and its
instruction
stream raises an exception. That exception delivers control at that same
low priority to the exception handler.
Do you want any of this to slow down a high priority interrupt ??
even by 20-50 cycles ??
I submit the answer is:: NO !
> And those three things can be tracked with a counter in Decode as they
> move down the pipeline to Retire. If the counter >0 then there is a
> flag change in flight and we don't accept a new interrupt. When count ==
> 0
> and Interrupt Enable flag == 1 then core accepts interrupts, which are
> injected at Decode and cause a light weight purge of the Fetch buffer.
Once you start adding mechanisms to track this and that and to deal
with different this and that--you should receive an indication that
you are not on the correct path.
{{Hint: make the problem go away for all time}}
> Another pipeline issue is Privileged Control Register (PCR) reads and
> writes.
> PCR's don't behave like general registers in that they are not renamed,
> and in general operations cannot be replayed or performed out of order.
While I have a way to read and write control registers with varying
privilege, a thread at privilege[k] can only read and write his own
CRs and those of the core on which it is currently running.
If you want to read/write control register data for lower privilege
threads, you can access the pointer in core.CR and then access
thread-state directly in memory. By the time control returns to the
low privilege level, all CRs will have been made resident in core.
That is the per thread Program-Status-Line is treated like a write
back cache.
> They behave more like atomic stores that must be performed at Retire
> and must not be bypassed by any memory and other PCR ops. (This is why
> many of the x86/x64 MSR ops are serialized with a pipeline drain.)
By converting them to real memory accesses, the problem solves itself.
> This affects what it can do with PCR inside the WoU if it causes a state
> change that cannot be undone, for example, reading the interrupt data
> FIFO.
Since the device is accessed through MMI/O space, and since My 66000
demands sequential consistency for MMI/O accesses, the LD of the
interrupt data FIFO cannot leave the confines of the core until
all pending memory references from the interrupted thread have
"been performed".
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-18 20:39 -0400 |
| Message-ID | <vrd3nc$3l9q1$1@dont-email.me> |
| In reply to | #111219 |
On 2025-03-18 6:49 p.m., MitchAlsup1 wrote: <snip> I am not following this. I think there needs to be some way to disable interrupts that should not be occurring. I think a diagram would help. +-------+--------+-----+--------+ | fetch | decode | ... | retire | +-------+--------+-----+--------+ | IRQ^ | .... | ... | INTDI | +-------+--------+-----+--------+ These two are happening at the same time. The INTDI (interrupt disable) should effectively cause the IRQ to be ignored. Instructions that are fetched after the IRQ are relying on interrupts disabled. Suppose there is an interrupt disable instruction in the pipeline that has not been performed yet (they are not done until the retire stage in Q+). So, interrupts are enabled when detected at an earlier pipeline stage (fetch). It turns out that the interrupt should not have been fetched from the interrupt queue as interrupts are about to be disabled by an earlier instruction. I think this matters because of the purpose of disabling the interrupts. There could be other instructions after the int disable including yet to be fetched instructions relying on the fact that interrupts are disabled. If the interrupt did not affect other aspects of the instruction being interrupted (it maybe just sets an interrupt bit in the pipeline register), I think it might be possible to handle this by having an interrupt enable flag in the pipeline registers. That way when the interrupt is disabled, all the interrupt enable flags in the pipeline registers could be cleared. When the disabled interrupt reaches retire, it would have to be logged (queued) so that it can be executed when interrupts are re-enabled. It gets worse with branches involved.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 01:22 +0000 |
| Message-ID | <717e1c6c0015ee03740574edd45b77a1@www.novabbs.org> |
| In reply to | #111221 |
On Wed, 19 Mar 2025 0:39:04 +0000, Robert Finch wrote:
> On 2025-03-18 6:49 p.m., MitchAlsup1 wrote:
> <snip>
>
> I am not following this. I think there needs to be some way to disable
> interrupts that should not be occurring. I think a diagram would help.
> +-------+--------+-----+--------+
> | fetch | decode | ... | retire |
> +-------+--------+-----+--------+
> | IRQ^ | .... | ... | INTDI |
> +-------+--------+-----+--------+
>
> These two are happening at the same time.
> The INTDI (interrupt disable) should effectively
> cause the IRQ to be ignored.
> Instructions that are fetched after the IRQ
> are relying on interrupts disabled.
a) there is a list of at least 7 places where interrupts can be disabled
..between the device[j] a core[k]
b) what I am addressing is disablement at the core.
c) any yes, I do have a way of disabling interrupts, but is generally
..reserved for nasty things like a system panic.
d) the typical "I'm done with req[k]" needs no interrupt disable.
e) certain architectures can choose to disable interrupts for a short
while
f) others can architect a system that does not need disablement.
Now, back to your ASCII-art::
If there is a interrupt disable instruction (or side effect) in the
pipeline, as seen at DECODE, the disable has already happened, and
the pipeline is just waiting for the event to become manifest. This
is that window of uncertainty.
> Suppose there is an interrupt disable instruction in the pipeline that
> has not been performed yet
As seen at DECODE it has already happened;
as seen at RETIRE it remains pending.
Different ends of the pipeline are allowed/required to know things
differently.
> (they are not done until the retire stage in
> Q+). So, interrupts are enabled when detected at an earlier pipeline
> stage (fetch). It turns out that the interrupt should not have been
> fetched from the interrupt queue as interrupts are about to be disabled
> by an earlier instruction.
This is that tangled web some weave.
> I think this matters because of the purpose
> of disabling the interrupts. There could be other instructions after the
> int disable including yet to be fetched instructions relying on the fact
> that interrupts are disabled.
If one bothers to disable core from seeing interrupts in My 66000,
The disable happens in program order, and is made to appear as if in
program order.
Likewise, if one enables core interrupts, the instruction following the
enable can take an interrupt (before it executes).
But you seem to be missing the point--it is possible (and I would argue
beneficial) to architect your interrupts such that interrupt disable is
not necessary >98& of the time. You do it when required, you don't when
you can get away with out it.
Completion interrupts ("I'm done with blah[k]") should not need to DIs.
> If the interrupt did not affect other aspects of the instruction being
> interrupted (it maybe just sets an interrupt bit in the pipeline
> register), I think it might be possible to handle this by having an
> interrupt enable flag in the pipeline registers.
If you head in that direction, you need to transfer control to the ISR
at the front of the pipeline, so that a mispredicted branch backs-up
to the 1st instruction in ISR, and then throw the window away with the
normal logic, leaving IP pointing at the branch or branch target.
> That way when the
> interrupt is disabled, all the interrupt enable flags in the pipeline
> registers could be cleared. When the disabled interrupt reaches retire,
> it would have to be logged (queued) so that it can be executed when
> interrupts are re-enabled.
It is for all these reason, I counsel you to device a system where the
typical interrupt needs to disable nothing.
> It gets worse with branches involved.
Which is why you want greater orthogonality wrt interrupts and IE-bit.
[toc] | [prev] | [next] | [standalone]
| From | Robert Finch <robfi680@gmail.com> |
|---|---|
| Date | 2025-03-18 23:22 -0400 |
| Message-ID | <vrddai$3t52b$1@dont-email.me> |
| In reply to | #111222 |
On 2025-03-18 9:22 p.m., MitchAlsup1 wrote:
> On Wed, 19 Mar 2025 0:39:04 +0000, Robert Finch wrote:
>
>> On 2025-03-18 6:49 p.m., MitchAlsup1 wrote:
>> <snip>
>>
> a) there is a list of at least 7 places where interrupts can be disabled
> ..between the device[j] a core[k]
> b) what I am addressing is disablement at the core.
> c) any yes, I do have a way of disabling interrupts, but is generally
> ..reserved for nasty things like a system panic.
> d) the typical "I'm done with req[k]" needs no interrupt disable.
> e) certain architectures can choose to disable interrupts for a short
> while
> f) others can architect a system that does not need disablement.
>
> Now, back to your ASCII-art::
A little more thought and I realized my art did not deal with the issue.
I did miss the point. I see now that the IRQ could simply be checked at
the retire stag to see if it is still enabled. If no longer enabled it
could be treated like a branch miss, and the original execution path
restored. But the issue was the IRQ has already been popped from the
input fifo. So, how does it get back into play? I think one mechanism
that might work is to just ignore it as the interrupting device may
resend the IRQ if it did not get processed withing a reasonable time.
And it is likely to be a rare occurrence. Another option might be to
queue the IRQ misses and feed them back. A lot of hardware for something
that is not going to happen often.
I had this issue "fixed" at one time using software to provide an
interrupt enable / disable ramp. Had sixteen NOPs during which an
interrupt could occur after it was disabled. Kinda ugly, worked with a
shorter pipeline.
> If one bothers to disable core from seeing interrupts in My 66000,
> The disable happens in program order, and is made to appear as if in
> program order.
>
> Likewise, if one enables core interrupts, the instruction following the
> enable can take an interrupt (before it executes).
>
> But you seem to be missing the point--it is possible (and I would argue
> beneficial) to architect your interrupts such that interrupt disable is
> not necessary >98& of the time. You do it when required, you don't when
> you can get away with out it.
>
> Completion interrupts ("I'm done with blah[k]") should not need to DIs.
>
>> That way when the
>> interrupt is disabled, all the interrupt enable flags in the pipeline
>> registers could be cleared. When the disabled interrupt reaches retire,
>> it would have to be logged (queued) so that it can be executed when
>> interrupts are re-enabled.
>
> It is for all these reason, I counsel you to device a system where the
> typical interrupt needs to disable nothing.
>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-03-19 13:54 +0000 |
| Message-ID | <Z%zCP.605106$OrR5.531155@fx18.iad> |
| In reply to | #111219 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Tue, 18 Mar 2025 18:51:57 +0000, EricP wrote: > >> This affects what it can do with PCR inside the WoU if it causes a state >> change that cannot be undone, for example, reading the interrupt data >> FIFO. > >Since the device is accessed through MMI/O space, and since My 66000 >demands sequential consistency for MMI/O accesses, the LD of the >interrupt data FIFO cannot leave the confines of the core until >all pending memory references from the interrupted thread have >"been performed". Be careful when relying on the ordering of outbound MMI/O accesses. They're not ordered with respect to DMA accesses initiated from the device. With PCI Express, software can also enable RO (Relaxed Ordering) which changes the normal fairly strict ordering rules, particulary with respect to non-posted transactions vis a vis posted transactions.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-19 15:56 +0000 |
| Message-ID | <0b07380cca4aa2c6c6f9b649e37e0a05@www.novabbs.org> |
| In reply to | #111225 |
On Wed, 19 Mar 2025 13:54:01 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Tue, 18 Mar 2025 18:51:57 +0000, EricP wrote: > >> >>> This affects what it can do with PCR inside the WoU if it causes a state >>> change that cannot be undone, for example, reading the interrupt data >>> FIFO. >> >>Since the device is accessed through MMI/O space, and since My 66000 >>demands sequential consistency for MMI/O accesses, the LD of the >>interrupt data FIFO cannot leave the confines of the core until >>all pending memory references from the interrupted thread have >>"been performed". > > Be careful when relying on the ordering of outbound MMI/O accesses. > They're not > ordered with respect to DMA accesses initiated from the device. When device DMA gets translated into MMI/O space my HostBridge will treat it as sequentially consistent. When device DMA gets translated into DRAM space my HostBridge will treat it as casually ordered. > With PCI Express, software can also enable RO (Relaxed Ordering) which > changes the normal fairly strict ordering rules, particulary with > respect > to non-posted transactions vis a vis posted transactions.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-03-17 21:49 +0000 |
| Message-ID | <ef12021b16a514c71a5cab2f0efa60c7@www.novabbs.org> |
| In reply to | #111209 |
On Mon, 17 Mar 2025 18:33:09 +0000, EricP wrote: > Michael S wrote: >> On Mon, 17 Mar 2025 13:38:12 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: ------------------ >> >> The problem Robert is talking about arises when there are many >> interrupt source and many target CPUs. >> The required routing/prioritization/acknowledgment logic (at least a >> naive logic I am having in mind) would be either non-scalable or >> relatively complicated. Process of selection for the second case will >> take multiple cycles (I am thinking about ring). > > Another problem is what does the core do with the in flight > instructions. > > Method 1 is simplest, it injects the interrupt request at Retire > as that's where the state of everything is synchronized. > The consequence is that, like exceptions, the in flight instructions all > get purged, and we save the committed RIP, RSP and interrupt control > word. > While that might be acceptable for a 5 stage in-order pipeline, > it could be pretty expensive for an OoO 200+ instruction queue > potentially tossing hundreds of cycles of near finished work. Lowest interrupt Latency Highest waste of power (i.e., work) > Method 2 pipelines the switch by injecting the interrupt request at > Fetch. > Decode converts the request to a special uOp that travels down the IQ > to Retire and allows all the older work to complete. > This is more complex as it requires a two phase hand-off from the > Interrupt Control Unit (ICU) to the core as a branch mispredict in the > in flight instructions might cause a tentative interrupt acceptance to > later be withdrawn. Interrupt latency is dependent on executing instructions, Lowest waste of power But note: In most cases, it already took the interrupt ~150 nanoseconds to arrive at the interrupt service port. 1 trip from device to DRAM (possibly serviced by L3), 1 trip from DRAM back to device, 1 tip from device to interrupt service port; and 4 DRAM (or L3) accesses to log interrupt into table. Also, in most cases, the 200-odd instructions in the window will finish in 100-cycles or as little as 20ns--but if the FDIV unit is saturated, interrupt latency could be as high as 640 cycles and as long as 640ns. > The ICU believes the core is in a state to accept a higher priority > interrupt. It sends a request to core, which checks its current state > and > sends back an immediate INT_ACK if _might_ accept and stalls Fetch, or a > NAK. In My 66000, ICU knows nothing about the priority level (or state) of any core in the system. Instead, when a new higher priority interrupt is raised, the ISP broadcasts a 64-bit mask indicating which priority levels in the interrupt table have pending inter- rupts with an MMI/O message to the address of the interrupt table. All cores monitoring that interrupt table capture the broadcast, and each core decides to negotiate for an (not that) interrupt by requesting the highest priority interrupt from the table. When the request returns, and it is still at a higher priority than the core is running, core performs interrupt control transfer. If the interrupt is below the core's priority it is returned to ISP as if NAKed. Prior to interrupt control transfer, core remains running what- ever it was running--and all the interrupt stuff is done by state machines at the edge of the core and the L3/DRAM controller. > When the special uOp reaches Retire, it sends a signal to Fetch which > then sends an INT_ACCEPT signal to ICU to complete the handoff. > If a branch mispredict occurs that causes interrupts to be disabled, > then Fetch sends an INT_REJECT to ICU, and unstalls its fetching. > (Yes that is not optimal - make it work first, make it work well > second.) > > This also raises a question about what the ICU is doing during this > long latency handoff. One wouldn't want ICU to sit idle so it might > have to manage the handoff of multiple interrupts to multiple cores > at the same time, each as its own little state machine. One must assume that ISP is capable of taking a new interrupt from a device every 5-ish cycles and interrupt handoff is in the range of 50 cycles, and that each interrupt could be to a different interrupt table. My 66000 ISP treats successive requests to any one table as strongly ordered, and requests to different tables as completely unordered. > One should see that this decision on how the core handles the > handoff has a large impact on the design complexity of the ICU. I did not "see" that in My 66000's interrupt architecture. The ISP complexity is fixed, and the core's interrupt negotiator is a small state machine (~10-states). ISP essentially performs 4-5 64-bit memory accesses, and possibly 1 MMI/O 64-bit broadcast on arrival of MSI-X interrupt. Then if a core negotiates, it performs 3 more memory accesses per negotiator.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.arch
csiph-web