Looks good, my BTI capable machine continues booting with this applied.

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.

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.

In D24066#616957, @emaste wrote:

Is this waiting on anything?

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?

In D26519#590130, @emaste wrote:

See D26510

In D26177#586533, @emaste wrote:

I wonder if we can upstream this too

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).

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

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().

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.

In D25839#573329, @rpokala wrote:

So this is the moral equivalent of ipmitool chassis bootdev bios?

In D26130#581703, @alc wrote:

I'm curious to see the output from "sysctl vm.phys_segs" on this machine.

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?

In D26130#581023, @markj wrote:

Instead of modifying vm_phys.c to have some knowledge of superpage reservations, could we instead allocation a reservation array per vm_phys_seg, at least in the VM_PHYSSEG_SPARSE case? I think that would keep the layering clean, and make it easy to solve the issue I pointed out in vm_reserv_from_page().