Thanks Andrew, could you (or anybody else) help merge that? My commit bit is taking a nap at the moment.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 25 2024
Jul 24 2024
Oct 12 2023
Looks good, my BTI capable machine continues booting with this applied.
Mar 30 2022
Mar 29 2022
Mar 25 2022
Mar 24 2022
Feb 17 2021
You can check the IPMI Specification, sec 12.5 for info on SSIF Multi-part Read Transactions
D28340's approach of letting all CPUs get targeted by an ITS removes the need for moving around SI_SUB_SMP.
D28340's approach of letting all CPUs get targeted by an ITS removes the need for changing this initialization.
Feb 16 2021
Jan 25 2021
In D28340#633881, @andrew wrote:We need to limit which CPUs we send these interrupts to on the original dual socket ThunderX as it is unable to forward them between the two sockets.
Dec 14 2020
In D24066#616957, @emaste wrote:Is this waiting on anything?
Dec 4 2020
Nov 13 2020
Oct 22 2020
Oct 15 2020
Oct 14 2020
Oct 13 2020
Thanks for fixing this. Grepping around, I believe vm_dumpset.h should also be included in:
This increases bss by ~1.5 MiB
This works for my case, but I'm not sure if this will be a problem for other platforms, or maybe for downstream codebases?
Another approach could be to just all interrupts to target the boot cpu, maybe before ap startup and maybe apply proximity restrictions after ap startup?
Oct 12 2020
Sep 30 2020
Sep 21 2020
In D26519#590130, @emaste wrote:See D26510
Sep 10 2020
In D26177#586533, @emaste wrote:I wonder if we can upstream this too
Sep 9 2020
In D26365#586260, @manu wrote:Thanks !
My investigation of this problem 1 year ago lead me to think it was relocation related but I'm clueless on how that work.
I'll try to test that asap (especially arm where I don't think we had a problem).
Sep 8 2020
I've tracked this down to a particular use-after-free type bug in edk2: https://www.mail-archive.com/devel@edk2.groups.io/msg25730.html
Aug 31 2020
In D26131#582102, @jhb wrote:In general it seems like there's an implicit assumption that nothing will ask
for a PA that isn't in dump_avail[], and if it does we just return the wrong
page since we just return some offset relative to the previous dump_avail
entry that overflows into the next entry's bitmap? It would be annoying to
fix as it means all the places that call _kvm_pa_to_bit(), and or adding some
kind of _kvm_has_pa().
Aug 27 2020
In D26190#582462, @markj wrote:Can we reuse the algorithm from is_dumpable()? That is, if the PA corresponds
to a vm_page, use a flag to decide whether the page is to be included in the
minidump, otherwise include it so long as the PA is in dump_avail[].
In D26190#582299, @kib wrote:If dump bitmap becomes so large, may be it is better to get rid of it at all ?
You can use vm_page aflags to track dumpable state.
Aug 26 2020
In D25839#573329, @rpokala wrote:So this is the moral equivalent of ipmitool chassis bootdev bios?
Aug 25 2020
In D26130#581703, @alc wrote:I'm curious to see the output from "sysctl vm.phys_segs" on this machine.
Aug 24 2020
Adding bitset.h to vm_page.h breaks the vhci driver. D26177 fixes that.
I augmented vm_phys_seg with a void *md_first field that is used for the pointer to the starting entry in pv_table. Is void * alright, or should I be making some new md_something type for the field?