- User Since
- Sep 10 2014, 9:01 PM (197 w, 1 d)
Looks good to me.
Wed, Jun 20
Approved if you fix the #if 0 bit.
Fri, Jun 15
Don't you want strcmp() == 0?
It's mildly stupid, since the universe of pci* isn't big, but I think I would prefer a check for "pci" || "pciex" to just checking the first three characters.
Mon, Jun 11
Tue, Jun 5
It's been another couple weeks. Any objections or approvals?
Mon, Jun 4
Wed, May 30
Sat, May 26
This looks good to me, though I haven't tested on P8.
On POWER9, I think the lock is unnecessary (the ISA spec doesn't mention it).
Fri, May 25
Any other thoughts? I'd like to get this in soon since it is blocking other things.
May 20 2018
Fix style and spelling issues in man pages.
Probe for pending devices at the end of each pass and after modules loaded. Add documentation.
See the comment on line 467 about powernv_smp_ap_init(). Otherwise, looks good.
May 19 2018
Approved if you also install it to EXC_HEA.
May 18 2018
This looks good, even if the deice tree situation is a bit lamentable. Two questions:
- Is there a document describing this that we can reference?
- If this is just part of the PowerNV platform, maybe the code belongs in platform_powernv.c instead?
May 14 2018
Thanks -- I'll tweak the implementation to handle KLDs properly and write a man page, then update this diff.
May 13 2018
Any further comments? I'd really like to get this, or something like it, in.
May 8 2018
We should do the same thing (check fdtbootcpu rather than PIR) on PowerNV too. Thanks for the work on this patch!
May 7 2018
Looks good to me. I haven't tested it, of course -- is this working well for you?
This is an interesting problem that I need to think about -- thanks for identifying it! I think this particular patch is not the right one, so let's put a pin in this for a couple days.
The CPU is stored in the device tree in one of two ways:
- As an ihandle "cpu" in /chosen
- The "fdtbootcpu" integer property from /chosen
May 6 2018
May 4 2018
May 1 2018
Apr 30 2018
Simplify logic dealing with pending attachments.
Apr 25 2018
We should fix that, too, though. This code assumes that we are booting on CPU 0 -- the same assumption could continue as a stopgap until we figure out a reliable way to evaluate the boot processor.
Apr 24 2018
Is there a reason not to just adopt the PowerNV version of this code, which already does the right thing?
Apr 23 2018
Apr 19 2018
Apr 18 2018
Apr 17 2018
This looks great, with one nit about the way you determine whether VSX is available.
Apr 5 2018
Mar 16 2018
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.
Mar 15 2018
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).
Mar 14 2018
Mar 13 2018
Use label arithmetic rather than instruction counting, which is much more robust.
Mar 11 2018
Looks good. Thanks for doing this!
Mar 7 2018
Mar 6 2018
Minor cleanups. Fix Book-E.
Mar 5 2018
Fix fault when synchronizing icache.
Mar 4 2018
- Fix graphics console on pSeries
- Apparent PS3 bugs fixed by other patches (this was only triggering latent problems)
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
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?
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.