Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 21, 2023 at 10:23:53PM -0500, Scott Cheloha wrote: > On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > > > > This is the next patch in the clock interrupt reorganization series. > > > > > > > > > > > > Before we continue breaking up the hardclock(9) we need to detour > > > > > > into > > > > > > the MD code. > > > > > > > > > > > > This patch divides the "initialization" parts of cpu_initclocks() > > > > > > from > > > > > > the "start the clock interrupt" parts. Seprating the two parts > > > > > > leaves > > > > > > initclocks() an opportunity to prepare the primary CPU for clock > > > > > > interrupt dispatch in a machine-independent manner before actually > > > > > > pulling the trigger. It's nearly impossible to do any MI setup > > > > > > during > > > > > > initclocks() because cpu_initclocks() does everything in one go: > > > > > > both > > > > > > initialization and kickoff are done when cpu_initclocks() returns. > > > > > > > > > > > > Many platforms have a "cpu_startclock()" function, so this patch > > > > > > takes > > > > > > that de facto standard and makes it a rule: cpu_startclock() is now > > > > > > required. It is prototyped in sys/systm.h and every platform must > > > > > > implement it. > > > > > > > > > > > > The revised initclocks() sequence is then: > > > > > > > > > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > > > > >hz, stathz, and profhz are initialized. All the machine > > > > > >independent setup in step (2) (currently) depends upon > > > > > >these machine-dependent values. > > > > > > > > > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > > > > > > > > >In a later step I will move the full contents of clockintr_init() > > > > > >up into initclocks() and get rid of clockintr_init() entirely. > > > > > > > > > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > > > > >clock interrupt dispatch cycle on the primary CPU. > > > > > > > > > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > > > > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > > > > > > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > > > > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > > > > > here. Everything else is relatively straightforward, though I may > > > > > > have missed a few stray variables here or there. > > > > > > > > > > > > Test results? Ok? > > > > > > > > > > Here is an updated patch that removes several MD prototypes for > > > > > cpu_startclock() that I missed the first time through. > > > > > > > > > > I went back and tested these again: > > > > > > > > > > - amd64 (lapic) > > > > > - arm64 > > > > > - i386 (lapic) > > > > > - powerpc/macppc > > > > > - mips64/octeon (loongson should be fine) > > > > > - sparc64 (sys_tick; tick/stick should be fine) > > > > > > > > > > arm/armv7 and riscv64 were tested under the previous version, but I > > > > > would appreciate a second compile-test to make sure the header changes > > > > > in the updated patch did not break the build (CC phessler@, jsg@). > > > > > > > > > > I am still seeking compile/boot-tests for the following: > > > > > > > > > > - alpha > > > > > - hppa > > > > > - m88k/luna88k > > > > > > > > if you are really interested in doing this [...] > > > > > > "really interested" is a bit strong. As always, my primary goal is > > > not to break anything when I make a commit. > > > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > > completely sure I didn't screw something up. > > > > > > > [...] you could run this in nono since you're just looking for > > > > a compile/boot test. > > > > > > Apparently the license forbids redistribution. Super annoying. > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > > question answered. you aren't redistributing anything. > > FWIW, I think vmctl/vmd have a nicer user interface. Same :) > > I feel like I'm... boxing... with nono, not using it.
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
Hello, and sorry for delay.
OpenBSD/luna88k GENERIC.MP kernel with your diff boots up normally on my
real hardware.
I am trying to "make build" on that kernel and it is working now, maybe
it takes more 1~2 days.
-- aoyama
On 2023/08/20 3:44, Scott Cheloha wrote:
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
This is the next patch in the clock interrupt reorganization series.
Before we continue breaking up the hardclock(9) we need to detour into
the MD code.
This patch divides the "initialization" parts of cpu_initclocks() from
the "start the clock interrupt" parts. Seprating the two parts leaves
initclocks() an opportunity to prepare the primary CPU for clock
interrupt dispatch in a machine-independent manner before actually
pulling the trigger. It's nearly impossible to do any MI setup during
initclocks() because cpu_initclocks() does everything in one go: both
initialization and kickoff are done when cpu_initclocks() returns.
Many platforms have a "cpu_startclock()" function, so this patch takes
that de facto standard and makes it a rule: cpu_startclock() is now
required. It is prototyped in sys/systm.h and every platform must
implement it.
The revised initclocks() sequence is then:
1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures
hz, stathz, and profhz are initialized. All the machine
independent setup in step (2) (currently) depends upon
these machine-dependent values.
2. Compute intervals using hz, stathz, and profhz.
In a later step I will move the full contents of clockintr_init()
up into initclocks() and get rid of clockintr_init() entirely.
3. Call cpu_startclock(). At minimum, cpu_startclock() starts the
clock interrupt dispatch cycle on the primary CPU.
I have compiled/booted this patch on amd64 (lapic path), arm64, i386
(lapic path), macppc, octeon, and sparc64 (sun4v).
I am looking for compile/boot tests on alpha, armv7, hppa, landisk,
luna88k, powerpc64, and riscv64. I think armv7 is the tricky one
here. Everything else is relatively straightforward, though I may
have missed a few stray variables here or there.
Test results? Ok?
Here is an updated patch that removes several MD prototypes for
cpu_startclock() that I missed the first time through.
I went back and tested these again:
- amd64 (lapic)
- arm64
- i386 (lapic)
- powerpc/macppc
- mips64/octeon (loongson should be fine)
- sparc64 (sys_tick; tick/stick should be fine)
arm/armv7 and riscv64 were tested under the previous version, but I
would appreciate a second compile-test to make sure the header changes
in the updated patch did not break the build (CC phessler@, jsg@).
I am still seeking compile/boot-tests for the following:
- alpha
- hppa
- m88k/luna88k
- powerpc64
- sh/landisk
Test results? Ok?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.113
diff -u -p -r1.113 kern_clock.c
--- kern/kern_clock.c 12 Aug 2023 13:19:28 - 1.113
+++ kern/kern_clock.c 19 Aug 2023 18:16:16 -
@@ -103,6 +103,9 @@ initclocks(void)
profclock_period = 10 / profhz;
inittimecounter();
+
+ /* Start dispatching clock interrupts on the primary CPU. */
+ cpu_startclock();
}
/*
Index: sys/systm.h
===
RCS file: /cvs/src/sys/sys/systm.h,v
retrieving revision 1.164
diff -u -p -r1.164 systm.h
--- sys/systm.h 5 Aug 2023 20:07:56 - 1.164
+++ sys/systm.h 19 Aug 2023 18:16:17 -
@@ -243,6 +243,7 @@ voidinitclocks(void);
void inittodr(time_t);
void resettodr(void);
void cpu_initclocks(void);
+void cpu_startclock(void);
void startprofclock(struct process *);
void stopprofclock(struct process *);
Index: arch/alpha/alpha/clock.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v
retrieving revision 1.28
diff -u -p -r1.28 clock.c
--- arch/alpha/alpha/clock.c25 Jul 2023 18:16:19 - 1.28
+++ arch/alpha/alpha/clock.c19 Aug 2023 18:16:17 -
@@ -193,7 +193,11 @@ cpu_initclocks(void)
stathz = hz;
profhz = stathz;
clockintr_init(0);
+}
+void
+cpu_startclock(void)
+{
clockintr_cpu_init(NULL);
/*
Index: arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.286
diff -u -p -r1.286 machdep.c
--- arch/amd64/amd64/machdep.c 27 Jul 2023 00:28:25 - 1.286
+++ arch/amd64/amd64/machdep.c 19 Aug 2023 18:16:18 -
@@ -227,6 +227,7 @@ paddr_t avail_end;
void (*delay_func)(int) = i8254_delay;
void (*initclock_func)(void) = i8254_initclocks;
+void (*startclock_func)(void) = i8254_start_both_clocks;
/*
* Format of boot information passed to us by 32-bit /boot
@@ -1878,6
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 21, 2023 at 10:34:53PM -0500, Scott Cheloha wrote: > > On Tue, Aug 22, 2023 at 11:28:25AM +0800, Kevin Lo wrote: > > On Mon, Aug 21, 2023 at 09:53:53PM -0500, Scott Cheloha wrote: > > > On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > > > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > > > > > - alpha > > > > > > > - hppa > > > > > > > - m88k/luna88k > > > > > > > > > > > > if you are really interested in doing this [...] > > > > > > > > > > "really interested" is a bit strong. As always, my primary goal is > > > > > not to break anything when I make a commit. > > > > > > > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > > > > completely sure I didn't screw something up. > > > > > > > > > > > [...] you could run this in nono since you're just looking for > > > > > > a compile/boot test. > > > > > > > > > > Apparently the license forbids redistribution. Super annoying. > > > > > > > > > > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > > > > question answered. you aren't redistributing anything. > > > > > > No, I mean that there is no binary for pkg_add, so I have to build it > > > by hand. Unless I'm missing something? > > > > Hi Scott, > > > > You could install emulators/nono, which is luna88k emulator. > > ??? > > I just tried that, it says there is no such thing. > > $ doas pkg_add nono > quirks-6.138 signed on 2023-08-20T20:51:44Z > Can't find nono > $ doas pkg_add emulators/nono > quirks-6.138 signed on 2023-08-20T20:51:44Z > file:emulators/: empty > Can't find nono > > What am I missing here? I'm really sorry, I'm stumped. Because of https://github.com/openbsd/ports/blob/master/emulators/nono/Makefile#L14, you need to install nono from the ports tree, thanks.
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Tue, Aug 22, 2023 at 11:28:25AM +0800, Kevin Lo wrote: > On Mon, Aug 21, 2023 at 09:53:53PM -0500, Scott Cheloha wrote: > > On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > > > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > > > > - alpha > > > > > > - hppa > > > > > > - m88k/luna88k > > > > > > > > > > if you are really interested in doing this [...] > > > > > > > > "really interested" is a bit strong. As always, my primary goal is > > > > not to break anything when I make a commit. > > > > > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > > > completely sure I didn't screw something up. > > > > > > > > > [...] you could run this in nono since you're just looking for > > > > > a compile/boot test. > > > > > > > > Apparently the license forbids redistribution. Super annoying. > > > > > > > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > > > question answered. you aren't redistributing anything. > > > > No, I mean that there is no binary for pkg_add, so I have to build it > > by hand. Unless I'm missing something? > > Hi Scott, > > You could install emulators/nono, which is luna88k emulator. ??? I just tried that, it says there is no such thing. $ doas pkg_add nono quirks-6.138 signed on 2023-08-20T20:51:44Z Can't find nono $ doas pkg_add emulators/nono quirks-6.138 signed on 2023-08-20T20:51:44Z file:emulators/: empty Can't find nono What am I missing here? I'm really sorry, I'm stumped.
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > > > This is the next patch in the clock interrupt reorganization series. > > > > > > > > > > Before we continue breaking up the hardclock(9) we need to detour into > > > > > the MD code. > > > > > > > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > > > > the "start the clock interrupt" parts. Seprating the two parts leaves > > > > > initclocks() an opportunity to prepare the primary CPU for clock > > > > > interrupt dispatch in a machine-independent manner before actually > > > > > pulling the trigger. It's nearly impossible to do any MI setup during > > > > > initclocks() because cpu_initclocks() does everything in one go: both > > > > > initialization and kickoff are done when cpu_initclocks() returns. > > > > > > > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > > > > that de facto standard and makes it a rule: cpu_startclock() is now > > > > > required. It is prototyped in sys/systm.h and every platform must > > > > > implement it. > > > > > > > > > > The revised initclocks() sequence is then: > > > > > > > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > > > >hz, stathz, and profhz are initialized. All the machine > > > > >independent setup in step (2) (currently) depends upon > > > > >these machine-dependent values. > > > > > > > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > > > > > > >In a later step I will move the full contents of clockintr_init() > > > > >up into initclocks() and get rid of clockintr_init() entirely. > > > > > > > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > > > >clock interrupt dispatch cycle on the primary CPU. > > > > > > > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > > > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > > > > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > > > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > > > > here. Everything else is relatively straightforward, though I may > > > > > have missed a few stray variables here or there. > > > > > > > > > > Test results? Ok? > > > > > > > > Here is an updated patch that removes several MD prototypes for > > > > cpu_startclock() that I missed the first time through. > > > > > > > > I went back and tested these again: > > > > > > > > - amd64 (lapic) > > > > - arm64 > > > > - i386 (lapic) > > > > - powerpc/macppc > > > > - mips64/octeon (loongson should be fine) > > > > - sparc64 (sys_tick; tick/stick should be fine) > > > > > > > > arm/armv7 and riscv64 were tested under the previous version, but I > > > > would appreciate a second compile-test to make sure the header changes > > > > in the updated patch did not break the build (CC phessler@, jsg@). > > > > > > > > I am still seeking compile/boot-tests for the following: > > > > > > > > - alpha > > > > - hppa > > > > - m88k/luna88k > > > > > > if you are really interested in doing this [...] > > > > "really interested" is a bit strong. As always, my primary goal is > > not to break anything when I make a commit. > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > completely sure I didn't screw something up. > > > > > [...] you could run this in nono since you're just looking for > > > a compile/boot test. > > > > Apparently the license forbids redistribution. Super annoying. > > so? install it, boot a luna88k "vm", test your diff, then you have your > question answered. you aren't redistributing anything. FWIW, I think vmctl/vmd have a nicer user interface. I feel like I'm... boxing... with nono, not using it.
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Tue, Aug 22, 2023 at 02:36:31AM +, Mike Larkin wrote: > On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > > > This is the next patch in the clock interrupt reorganization series. > > > > > > > > > > Before we continue breaking up the hardclock(9) we need to detour into > > > > > the MD code. > > > > > > > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > > > > the "start the clock interrupt" parts. Seprating the two parts leaves > > > > > initclocks() an opportunity to prepare the primary CPU for clock > > > > > interrupt dispatch in a machine-independent manner before actually > > > > > pulling the trigger. It's nearly impossible to do any MI setup during > > > > > initclocks() because cpu_initclocks() does everything in one go: both > > > > > initialization and kickoff are done when cpu_initclocks() returns. > > > > > > > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > > > > that de facto standard and makes it a rule: cpu_startclock() is now > > > > > required. It is prototyped in sys/systm.h and every platform must > > > > > implement it. > > > > > > > > > > The revised initclocks() sequence is then: > > > > > > > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > > > >hz, stathz, and profhz are initialized. All the machine > > > > >independent setup in step (2) (currently) depends upon > > > > >these machine-dependent values. > > > > > > > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > > > > > > >In a later step I will move the full contents of clockintr_init() > > > > >up into initclocks() and get rid of clockintr_init() entirely. > > > > > > > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > > > >clock interrupt dispatch cycle on the primary CPU. > > > > > > > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > > > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > > > > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > > > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > > > > here. Everything else is relatively straightforward, though I may > > > > > have missed a few stray variables here or there. > > > > > > > > > > Test results? Ok? > > > > > > > > Here is an updated patch that removes several MD prototypes for > > > > cpu_startclock() that I missed the first time through. > > > > > > > > I went back and tested these again: > > > > > > > > - amd64 (lapic) > > > > - arm64 > > > > - i386 (lapic) > > > > - powerpc/macppc > > > > - mips64/octeon (loongson should be fine) > > > > - sparc64 (sys_tick; tick/stick should be fine) > > > > > > > > arm/armv7 and riscv64 were tested under the previous version, but I > > > > would appreciate a second compile-test to make sure the header changes > > > > in the updated patch did not break the build (CC phessler@, jsg@). > > > > > > > > I am still seeking compile/boot-tests for the following: > > > > > > > > - alpha > > > > - hppa > > > > - m88k/luna88k > > > > > > if you are really interested in doing this [...] > > > > "really interested" is a bit strong. As always, my primary goal is > > not to break anything when I make a commit. > > > > The luna88k patch looks pretty straightfoward, but it's hard to be > > completely sure I didn't screw something up. > > > > > [...] you could run this in nono since you're just looking for > > > a compile/boot test. > > > > Apparently the license forbids redistribution. Super annoying. > > > > so? install it, boot a luna88k "vm", test your diff, then you have your > question answered. you aren't redistributing anything. No, I mean that there is no binary for pkg_add, so I have to build it by hand. Unless I'm missing something?
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 21, 2023 at 09:26:00PM -0500, Scott Cheloha wrote: > On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > > This is the next patch in the clock interrupt reorganization series. > > > > > > > > Before we continue breaking up the hardclock(9) we need to detour into > > > > the MD code. > > > > > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > > > the "start the clock interrupt" parts. Seprating the two parts leaves > > > > initclocks() an opportunity to prepare the primary CPU for clock > > > > interrupt dispatch in a machine-independent manner before actually > > > > pulling the trigger. It's nearly impossible to do any MI setup during > > > > initclocks() because cpu_initclocks() does everything in one go: both > > > > initialization and kickoff are done when cpu_initclocks() returns. > > > > > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > > > that de facto standard and makes it a rule: cpu_startclock() is now > > > > required. It is prototyped in sys/systm.h and every platform must > > > > implement it. > > > > > > > > The revised initclocks() sequence is then: > > > > > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > > >hz, stathz, and profhz are initialized. All the machine > > > >independent setup in step (2) (currently) depends upon > > > >these machine-dependent values. > > > > > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > > > > >In a later step I will move the full contents of clockintr_init() > > > >up into initclocks() and get rid of clockintr_init() entirely. > > > > > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > > >clock interrupt dispatch cycle on the primary CPU. > > > > > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > > > here. Everything else is relatively straightforward, though I may > > > > have missed a few stray variables here or there. > > > > > > > > Test results? Ok? > > > > > > Here is an updated patch that removes several MD prototypes for > > > cpu_startclock() that I missed the first time through. > > > > > > I went back and tested these again: > > > > > > - amd64 (lapic) > > > - arm64 > > > - i386 (lapic) > > > - powerpc/macppc > > > - mips64/octeon (loongson should be fine) > > > - sparc64 (sys_tick; tick/stick should be fine) > > > > > > arm/armv7 and riscv64 were tested under the previous version, but I > > > would appreciate a second compile-test to make sure the header changes > > > in the updated patch did not break the build (CC phessler@, jsg@). > > > > > > I am still seeking compile/boot-tests for the following: > > > > > > - alpha > > > - hppa > > > - m88k/luna88k > > > > if you are really interested in doing this [...] > > "really interested" is a bit strong. As always, my primary goal is > not to break anything when I make a commit. > > The luna88k patch looks pretty straightfoward, but it's hard to be > completely sure I didn't screw something up. > > > [...] you could run this in nono since you're just looking for > > a compile/boot test. > > Apparently the license forbids redistribution. Super annoying. > so? install it, boot a luna88k "vm", test your diff, then you have your question answered. you aren't redistributing anything. > > > - powerpc64 > > > > builds and boots on powerpc64 > > Noted. Thank you! >
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 21, 2023 at 10:10:58PM +, Mike Larkin wrote: > On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > > This is the next patch in the clock interrupt reorganization series. > > > > > > Before we continue breaking up the hardclock(9) we need to detour into > > > the MD code. > > > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > > the "start the clock interrupt" parts. Seprating the two parts leaves > > > initclocks() an opportunity to prepare the primary CPU for clock > > > interrupt dispatch in a machine-independent manner before actually > > > pulling the trigger. It's nearly impossible to do any MI setup during > > > initclocks() because cpu_initclocks() does everything in one go: both > > > initialization and kickoff are done when cpu_initclocks() returns. > > > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > > that de facto standard and makes it a rule: cpu_startclock() is now > > > required. It is prototyped in sys/systm.h and every platform must > > > implement it. > > > > > > The revised initclocks() sequence is then: > > > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > > >hz, stathz, and profhz are initialized. All the machine > > >independent setup in step (2) (currently) depends upon > > >these machine-dependent values. > > > > > > 2. Compute intervals using hz, stathz, and profhz. > > > > > >In a later step I will move the full contents of clockintr_init() > > >up into initclocks() and get rid of clockintr_init() entirely. > > > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > > >clock interrupt dispatch cycle on the primary CPU. > > > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > > here. Everything else is relatively straightforward, though I may > > > have missed a few stray variables here or there. > > > > > > Test results? Ok? > > > > Here is an updated patch that removes several MD prototypes for > > cpu_startclock() that I missed the first time through. > > > > I went back and tested these again: > > > > - amd64 (lapic) > > - arm64 > > - i386 (lapic) > > - powerpc/macppc > > - mips64/octeon (loongson should be fine) > > - sparc64 (sys_tick; tick/stick should be fine) > > > > arm/armv7 and riscv64 were tested under the previous version, but I > > would appreciate a second compile-test to make sure the header changes > > in the updated patch did not break the build (CC phessler@, jsg@). > > > > I am still seeking compile/boot-tests for the following: > > > > - alpha > > - hppa > > - m88k/luna88k > > if you are really interested in doing this [...] "really interested" is a bit strong. As always, my primary goal is not to break anything when I make a commit. The luna88k patch looks pretty straightfoward, but it's hard to be completely sure I didn't screw something up. > [...] you could run this in nono since you're just looking for > a compile/boot test. Apparently the license forbids redistribution. Super annoying. > > - powerpc64 > > builds and boots on powerpc64 Noted. Thank you!
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote:
> On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> > This is the next patch in the clock interrupt reorganization series.
> >
> > Before we continue breaking up the hardclock(9) we need to detour into
> > the MD code.
> >
> > This patch divides the "initialization" parts of cpu_initclocks() from
> > the "start the clock interrupt" parts. Seprating the two parts leaves
> > initclocks() an opportunity to prepare the primary CPU for clock
> > interrupt dispatch in a machine-independent manner before actually
> > pulling the trigger. It's nearly impossible to do any MI setup during
> > initclocks() because cpu_initclocks() does everything in one go: both
> > initialization and kickoff are done when cpu_initclocks() returns.
> >
> > Many platforms have a "cpu_startclock()" function, so this patch takes
> > that de facto standard and makes it a rule: cpu_startclock() is now
> > required. It is prototyped in sys/systm.h and every platform must
> > implement it.
> >
> > The revised initclocks() sequence is then:
> >
> > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures
> >hz, stathz, and profhz are initialized. All the machine
> >independent setup in step (2) (currently) depends upon
> >these machine-dependent values.
> >
> > 2. Compute intervals using hz, stathz, and profhz.
> >
> >In a later step I will move the full contents of clockintr_init()
> >up into initclocks() and get rid of clockintr_init() entirely.
> >
> > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the
> >clock interrupt dispatch cycle on the primary CPU.
> >
> > I have compiled/booted this patch on amd64 (lapic path), arm64, i386
> > (lapic path), macppc, octeon, and sparc64 (sun4v).
> >
> > I am looking for compile/boot tests on alpha, armv7, hppa, landisk,
> > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one
> > here. Everything else is relatively straightforward, though I may
> > have missed a few stray variables here or there.
> >
> > Test results? Ok?
>
> Here is an updated patch that removes several MD prototypes for
> cpu_startclock() that I missed the first time through.
>
> I went back and tested these again:
>
> - amd64 (lapic)
> - arm64
> - i386 (lapic)
> - powerpc/macppc
> - mips64/octeon (loongson should be fine)
> - sparc64 (sys_tick; tick/stick should be fine)
>
> arm/armv7 and riscv64 were tested under the previous version, but I
> would appreciate a second compile-test to make sure the header changes
> in the updated patch did not break the build (CC phessler@, jsg@).
>
> I am still seeking compile/boot-tests for the following:
>
> - alpha
> - hppa
> - m88k/luna88k
if you are really interested in doing this you could run this in nono since
you're just looking for a compile/boot test.
> - powerpc64
builds and boots on powerpc64
> - sh/landisk
>
> Test results? Ok?
>
> Index: kern/kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.113
> diff -u -p -r1.113 kern_clock.c
> --- kern/kern_clock.c 12 Aug 2023 13:19:28 - 1.113
> +++ kern/kern_clock.c 19 Aug 2023 18:16:16 -
> @@ -103,6 +103,9 @@ initclocks(void)
> profclock_period = 10 / profhz;
>
> inittimecounter();
> +
> + /* Start dispatching clock interrupts on the primary CPU. */
> + cpu_startclock();
> }
>
> /*
> Index: sys/systm.h
> ===
> RCS file: /cvs/src/sys/sys/systm.h,v
> retrieving revision 1.164
> diff -u -p -r1.164 systm.h
> --- sys/systm.h 5 Aug 2023 20:07:56 - 1.164
> +++ sys/systm.h 19 Aug 2023 18:16:17 -
> @@ -243,6 +243,7 @@ void initclocks(void);
> void inittodr(time_t);
> void resettodr(void);
> void cpu_initclocks(void);
> +void cpu_startclock(void);
>
> void startprofclock(struct process *);
> void stopprofclock(struct process *);
> Index: arch/alpha/alpha/clock.c
> ===
> RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 clock.c
> --- arch/alpha/alpha/clock.c 25 Jul 2023 18:16:19 - 1.28
> +++ arch/alpha/alpha/clock.c 19 Aug 2023 18:16:17 -
> @@ -193,7 +193,11 @@ cpu_initclocks(void)
> stathz = hz;
> profhz = stathz;
> clockintr_init(0);
> +}
>
> +void
> +cpu_startclock(void)
> +{
> clockintr_cpu_init(NULL);
>
> /*
> Index: arch/amd64/amd64/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
> retrieving revision 1.286
> diff -u -p -r1.286 machdep.c
> --- arch/amd64/amd64/machdep.c27 Jul 2023 00:28:25 - 1.286
> +++ arch/amd64/amd64/machdep.c19 Aug 2023 18:16:18 -
> @@ -227,6 +227,7 @@ paddr_t avail_end;
>
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote: > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > > > Before we continue breaking up the hardclock(9) we need to detour into > > the MD code. > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > the "start the clock interrupt" parts. Seprating the two parts leaves > > initclocks() an opportunity to prepare the primary CPU for clock > > interrupt dispatch in a machine-independent manner before actually > > pulling the trigger. It's nearly impossible to do any MI setup during > > initclocks() because cpu_initclocks() does everything in one go: both > > initialization and kickoff are done when cpu_initclocks() returns. > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > that de facto standard and makes it a rule: cpu_startclock() is now > > required. It is prototyped in sys/systm.h and every platform must > > implement it. > > > > The revised initclocks() sequence is then: > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > >hz, stathz, and profhz are initialized. All the machine > >independent setup in step (2) (currently) depends upon > >these machine-dependent values. > > > > 2. Compute intervals using hz, stathz, and profhz. > > > >In a later step I will move the full contents of clockintr_init() > >up into initclocks() and get rid of clockintr_init() entirely. > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > >clock interrupt dispatch cycle on the primary CPU. > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > here. Everything else is relatively straightforward, though I may > > have missed a few stray variables here or there. > > > > Test results? Ok? > > Here is an updated patch that removes several MD prototypes for > cpu_startclock() that I missed the first time through. > > I went back and tested these again: > > - amd64 (lapic) > - arm64 > - i386 (lapic) > - powerpc/macppc > - mips64/octeon (loongson should be fine) > - sparc64 (sys_tick; tick/stick should be fine) > > arm/armv7 and riscv64 were tested under the previous version, but I > would appreciate a second compile-test to make sure the header changes > in the updated patch did not break the build (CC phessler@, jsg@). Still builds on riscv64 and armv7.
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> This is the next patch in the clock interrupt reorganization series.
>
> Before we continue breaking up the hardclock(9) we need to detour into
> the MD code.
>
> This patch divides the "initialization" parts of cpu_initclocks() from
> the "start the clock interrupt" parts. Seprating the two parts leaves
> initclocks() an opportunity to prepare the primary CPU for clock
> interrupt dispatch in a machine-independent manner before actually
> pulling the trigger. It's nearly impossible to do any MI setup during
> initclocks() because cpu_initclocks() does everything in one go: both
> initialization and kickoff are done when cpu_initclocks() returns.
>
> Many platforms have a "cpu_startclock()" function, so this patch takes
> that de facto standard and makes it a rule: cpu_startclock() is now
> required. It is prototyped in sys/systm.h and every platform must
> implement it.
>
> The revised initclocks() sequence is then:
>
> 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures
>hz, stathz, and profhz are initialized. All the machine
>independent setup in step (2) (currently) depends upon
>these machine-dependent values.
>
> 2. Compute intervals using hz, stathz, and profhz.
>
>In a later step I will move the full contents of clockintr_init()
>up into initclocks() and get rid of clockintr_init() entirely.
>
> 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the
>clock interrupt dispatch cycle on the primary CPU.
>
> I have compiled/booted this patch on amd64 (lapic path), arm64, i386
> (lapic path), macppc, octeon, and sparc64 (sun4v).
>
> I am looking for compile/boot tests on alpha, armv7, hppa, landisk,
> luna88k, powerpc64, and riscv64. I think armv7 is the tricky one
> here. Everything else is relatively straightforward, though I may
> have missed a few stray variables here or there.
>
> Test results? Ok?
Here is an updated patch that removes several MD prototypes for
cpu_startclock() that I missed the first time through.
I went back and tested these again:
- amd64 (lapic)
- arm64
- i386 (lapic)
- powerpc/macppc
- mips64/octeon (loongson should be fine)
- sparc64 (sys_tick; tick/stick should be fine)
arm/armv7 and riscv64 were tested under the previous version, but I
would appreciate a second compile-test to make sure the header changes
in the updated patch did not break the build (CC phessler@, jsg@).
I am still seeking compile/boot-tests for the following:
- alpha
- hppa
- m88k/luna88k
- powerpc64
- sh/landisk
Test results? Ok?
Index: kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.113
diff -u -p -r1.113 kern_clock.c
--- kern/kern_clock.c 12 Aug 2023 13:19:28 - 1.113
+++ kern/kern_clock.c 19 Aug 2023 18:16:16 -
@@ -103,6 +103,9 @@ initclocks(void)
profclock_period = 10 / profhz;
inittimecounter();
+
+ /* Start dispatching clock interrupts on the primary CPU. */
+ cpu_startclock();
}
/*
Index: sys/systm.h
===
RCS file: /cvs/src/sys/sys/systm.h,v
retrieving revision 1.164
diff -u -p -r1.164 systm.h
--- sys/systm.h 5 Aug 2023 20:07:56 - 1.164
+++ sys/systm.h 19 Aug 2023 18:16:17 -
@@ -243,6 +243,7 @@ voidinitclocks(void);
void inittodr(time_t);
void resettodr(void);
void cpu_initclocks(void);
+void cpu_startclock(void);
void startprofclock(struct process *);
void stopprofclock(struct process *);
Index: arch/alpha/alpha/clock.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v
retrieving revision 1.28
diff -u -p -r1.28 clock.c
--- arch/alpha/alpha/clock.c25 Jul 2023 18:16:19 - 1.28
+++ arch/alpha/alpha/clock.c19 Aug 2023 18:16:17 -
@@ -193,7 +193,11 @@ cpu_initclocks(void)
stathz = hz;
profhz = stathz;
clockintr_init(0);
+}
+void
+cpu_startclock(void)
+{
clockintr_cpu_init(NULL);
/*
Index: arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.286
diff -u -p -r1.286 machdep.c
--- arch/amd64/amd64/machdep.c 27 Jul 2023 00:28:25 - 1.286
+++ arch/amd64/amd64/machdep.c 19 Aug 2023 18:16:18 -
@@ -227,6 +227,7 @@ paddr_t avail_end;
void (*delay_func)(int) = i8254_delay;
void (*initclock_func)(void) = i8254_initclocks;
+void (*startclock_func)(void) = i8254_start_both_clocks;
/*
* Format of boot information passed to us by 32-bit /boot
@@ -1878,6 +1879,12 @@ void
cpu_initclocks(void)
{
(*initclock_func)();
+}
+
+void
+cpu_startclock(void)
+{
+ (*startclock_func)();
}
void
Index: arch/amd64/amd64/lapic.c
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Mon, Aug 14, 2023 at 06:24:14PM +1000, Jonathan Matthew wrote: > On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > > This is the next patch in the clock interrupt reorganization series. > > > > Before we continue breaking up the hardclock(9) we need to detour into > > the MD code. > > > > This patch divides the "initialization" parts of cpu_initclocks() from > > the "start the clock interrupt" parts. Seprating the two parts leaves > > initclocks() an opportunity to prepare the primary CPU for clock > > interrupt dispatch in a machine-independent manner before actually > > pulling the trigger. It's nearly impossible to do any MI setup during > > initclocks() because cpu_initclocks() does everything in one go: both > > initialization and kickoff are done when cpu_initclocks() returns. > > > > Many platforms have a "cpu_startclock()" function, so this patch takes > > that de facto standard and makes it a rule: cpu_startclock() is now > > required. It is prototyped in sys/systm.h and every platform must > > implement it. > > > > The revised initclocks() sequence is then: > > > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures > >hz, stathz, and profhz are initialized. All the machine > >independent setup in step (2) (currently) depends upon > >these machine-dependent values. > > > > 2. Compute intervals using hz, stathz, and profhz. > > > >In a later step I will move the full contents of clockintr_init() > >up into initclocks() and get rid of clockintr_init() entirely. > > > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the > >clock interrupt dispatch cycle on the primary CPU. > > > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > > (lapic path), macppc, octeon, and sparc64 (sun4v). > > > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > > here. Everything else is relatively straightforward, though I may > > have missed a few stray variables here or there. > > > > Test results? Ok? > > Compiles on armv7 and boots on an Allwinner A20 machine using agtimer(4). > I don't think I have any armv7 systems using other timer devices. > Also compiles and boots on riscv64 (visionfive 2).
Re: all platforms: separate cpu_initclocks() from cpu_startclock()
On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote: > This is the next patch in the clock interrupt reorganization series. > > Before we continue breaking up the hardclock(9) we need to detour into > the MD code. > > This patch divides the "initialization" parts of cpu_initclocks() from > the "start the clock interrupt" parts. Seprating the two parts leaves > initclocks() an opportunity to prepare the primary CPU for clock > interrupt dispatch in a machine-independent manner before actually > pulling the trigger. It's nearly impossible to do any MI setup during > initclocks() because cpu_initclocks() does everything in one go: both > initialization and kickoff are done when cpu_initclocks() returns. > > Many platforms have a "cpu_startclock()" function, so this patch takes > that de facto standard and makes it a rule: cpu_startclock() is now > required. It is prototyped in sys/systm.h and every platform must > implement it. > > The revised initclocks() sequence is then: > > 1. Call cpu_initclocks(). At minimum, cpu_initclocks() ensures >hz, stathz, and profhz are initialized. All the machine >independent setup in step (2) (currently) depends upon >these machine-dependent values. > > 2. Compute intervals using hz, stathz, and profhz. > >In a later step I will move the full contents of clockintr_init() >up into initclocks() and get rid of clockintr_init() entirely. > > 3. Call cpu_startclock(). At minimum, cpu_startclock() starts the >clock interrupt dispatch cycle on the primary CPU. > > I have compiled/booted this patch on amd64 (lapic path), arm64, i386 > (lapic path), macppc, octeon, and sparc64 (sun4v). > > I am looking for compile/boot tests on alpha, armv7, hppa, landisk, > luna88k, powerpc64, and riscv64. I think armv7 is the tricky one > here. Everything else is relatively straightforward, though I may > have missed a few stray variables here or there. > > Test results? Ok? Compiles on armv7 and boots on an Allwinner A20 machine using agtimer(4). I don't think I have any armv7 systems using other timer devices.
