- User Since
- Sep 10 2014, 9:01 PM (183 w, 4 d)
Fri, Mar 16
I think there is also a subtlety for uncaught signals if the previous trap was a kernel fault, since you then end up in the wrong branch of the kernel/user if in trap() and probably crash.
Sure, it will deliver the signal. But the value of MSR when control is returned to userland may be wrong (it may even have MSR[PR] unset and return in supervisor mode if the previous trap on this CPU was in the kernel!) and it will resume execution in the wrong place if the signal is caught and handled.
Thu, Mar 15
I'm looking at this again. Does this actually work? HEA interrupts set HSRR0/HSSR1, which we don't save, so I think this will jump back to some random other memory location (whatever happened to be in SRR0).
Wed, Mar 14
Tue, Mar 13
Use label arithmetic rather than instruction counting, which is much more robust.
Sun, Mar 11
Looks good. Thanks for doing this!
Wed, Mar 7
Tue, Mar 6
Minor cleanups. Fix Book-E.
Mon, Mar 5
Fix fault when synchronizing icache.
Sun, Mar 4
- Fix graphics console on pSeries
- Apparent PS3 bugs fixed by other patches (this was only triggering latent problems)
Sat, Mar 3
Another thing to try with the Open Firmware crash is to set 'usefdt=1' in the loader. For me, either of these resolve the crash. Could you verify this on your hardware?
Thu, Mar 1
Tue, Feb 27
I have a few main worries about this, mostly also in the inline comments:
- I think this trashes userland vector registers, which is very bad.
- It breaks booting on Apple hardware.
- Is there really a performance benefit to this? The kernel tries pretty vigorously to avoid memcpy and no other architectures have vectorized in-kernel memcpy(), substantially to avoid the serious issues associated with concern 1, but also because it doesn't help much. I would imagine you would get much more benefit, with much less hassle, from optimizing the copy in libc, which would be 90% of the same code but with all the complex cases deleted.
Sat, Feb 24
Looks great to me.
Wed, Feb 21
Tue, Feb 20
cpu_subr64.S isn't really a great name, since it doesn't convey a ton of information. How about cpu_idle64.S? In any case, is there a reason it needs to be #included into locore64.S rather than built as an independent file?
Mon, Feb 19
I think this breaks 32-bit builds since ps_per_tick is too small there. I think it needs to be bumped to uint64_t.
Sun, Feb 18
Sat, Feb 17
Why would you want SLB on ppc32? It's only needed to support > 4 GB of VA space, but you can't have that by construction.
Feb 17 2018
Looks great to me (no testing, though).
Feb 16 2018
There is a yield instruction ("yield"), but it is a bit of a different thing. Earlier versions of POWER also do implement instructions that do this without going through reset (MSR[POW], notably). As a result, I have somewhat mixed feelings implementing this in the platform layer. Is there a reason to do it there rather than cpu.c, where the code for MSR[POW] etc. lives?
Feb 15 2018
Is cpu_idle() the right place for this? I'm not sure what the wake-up latency of this code is, but, if it involves restoring registers in software, it seems like it might be heavier-weight than intended for cpu_idle().
Feb 9 2018
Feb 3 2018
Feb 1 2018
Jan 31 2018
Yes, this is a WIP. Is there anything different about ARM EFI boot vs. amd64? I don't have any such hardware to test on, but I would guess this code can basically be copied and pasted.
Use new general FAT code.
The framework in the install to support this ended up being a little different. The updated diff is attached.
Jan 29 2018
There is intrinsically no difference between CHRP and PowerNV. Could you please update CHRP to match, including the BSP 0 code, (copy-and-paste is fine) and test it on your POWER8 system? I don't have access to any POWER8 hardware and the moment and the risk of breaking Power[K]VM is high.
Jan 28 2018
Jan 26 2018
I like the approach. Why doesn't it work if BSP is non-zero? Doesn't this code arrange for the BSP to always be zero?
This looks great.
Jan 25 2018
Jan 24 2018
This is conceptually unworkable, for two core reasons. First, the PIR register is unreliable when set, especially on VMs in the face of movement to another core. We've tried to remove all uses of PIR in code that does not know it is reliable (all generic code) for this reason. The real kicker, though, is that on some of our supported hardware (Apple G4 machines, for instance), PIR needs to be set by *us* and all CPUs boot with identical PIR. In the face of this, the proposed mechanism simply cannot work.
Jan 19 2018
I think this is a great idea. Don't see any obvious problems with the implementation.
Jan 17 2018
I think this is fine. Have you tested on loader-using hardware (Apple, IBM paravirtualized)? I have some vague memory this was needed on Apple hardware.
Nice catch. Thanks!
Jan 15 2018
I agree with Warner's comments -- if there is any other way to do the endian conversions at all, we should.
Looks good to me. Thanks!
Jan 13 2018
Works just fine on PowerPC.
Jan 12 2018
It would be good if we could add some #ifdef here such that it still builds without both PSERIES and POWERNV in the kernel (especially the latter, as committing this will break all custom PSERIES kernels as-is). Other than that, it looks good to me.