- Fix graphics console on pSeries
- Apparent PS3 bugs fixed by other patches (this was only triggering latent problems)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mar 4 2018
Mar 3 2018
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?
Mar 1 2018
In D14538#305284, @pdk_semihalf.com wrote:I have a question about your 1st worry. Is this a scenario in which we are doing memcpy in eg. interrupt filter code? If not, could you explain what are you worry about?
In D14499#304559, @breno.leitao_gmail.com wrote:If the above analyzes is correct, It seems that a function ends up with a conditional branch, so, if the condition is not reached, then it moved to the function epilogue, which is 0x0.
(gdb) x/10i 0x000000007dbe02f0 0x7dbe02f0: std r0,296(r1) 0x7dbe02f4: mfdar r0 0x7dbe02f8: std r0,304(r1) 0x7dbe02fc: mfdsisr r0 0x7dbe0300: std r0,312(r1) 0x7dbe0304: bcl 20,4*cr7+so,0x7dbe0310 0x7dbe0308: .long 0x0 0x7dbe030c: .long 0x87eef8 0x7dbe0310: mflr r2 0x7dbe0314: ld r1,0(r2)But this is still very confusing, since there just two places in the code we use mfdsisr, and it is always with %r31.
I am wondering if something caused the code to leave the kernel code, and now I am debugging somewhere else (OpenFirmware?).
Feb 27 2018
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.
Feb 24 2018
Looks great to me.
Feb 21 2018
Feb 20 2018
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?
In D14330#302660, @pdk_semihalf.com wrote:In D14330#302615, @nwhitehorn wrote:In D14330#302546, @pdk_semihalf.com wrote:Could you tell me more about scenario in which we branch to rstcode from software? I was looking for it but I found nothing.
Line 99 of locore64.S.
Thanks. I will clear whole register, right?
Feb 19 2018
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.
In D14330#302546, @pdk_semihalf.com wrote:Could you tell me more about scenario in which we branch to rstcode from software? I was looking for it but I found nothing.
Feb 18 2018
In D14405#302166, @jhibbits wrote:In D14405#302165, @nwhitehorn wrote: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.
I wasn't thinking correctly... I was thinking about the >4GB PA, which that doesn't cover (can we do >4GB PA in 32-bit space on Book-S generically? I only know of the MPC7450-class means, but I don't think that's generic).
Feb 17 2018
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.
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[64] 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
Looks great!
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.