Re: [PATCH v2 00/12] x86: major paravirt cleanup
From: Peter Zijlstra <peterz@infradead.org>
Date: 2020-12-16 08:43:14
Also in:
kvm, lkml, virtualization, xen-devel
On Tue, Dec 15, 2020 at 06:38:02PM -0600, Josh Poimboeuf wrote:
On Tue, Dec 15, 2020 at 03:54:08PM +0100, Peter Zijlstra wrote:quoted
The problem is that a single instance of unwind information (ORC) must capture and correctly unwind all alternatives. Since the trivially correct mandate is out, implement the straight forward brute-force approach: 1) generate CFI information for each alternative 2) unwind every alternative with the merge-sort of the previously generated CFI information -- O(n^2) 3) for any possible conflict: yell. 4) Generate ORC with merge-sort Specifically for 3 there are two possible classes of conflicts: - the merge-sort itself could find conflicting CFI for the same offset. - the unwind can fail with the merged CFI.So much algorithm.
:-) It's not really hard, but it has a few pesky details (as always).
Could we make it easier by caching the shared per-alt-group CFI state somewhere along the way?
Yes, but when I tried it grew the code required. Runtime costs would be less, but I figured that since alternatives are typically few and small, that wasn't a real consideration. That is, it would basically cache the results of find_alt_unwind(), but you still need find_alt_unwind() to generate that data, and so you gain the code for filling and using the extra data structure. Yes, computing it 3 times is naf, but meh.
[ 'offset' is a byte offset from the beginning of the group. It could be calculated based on 'orig_insn' or 'orig_insn->alts', depending on whether 'insn' is an original or a replacement. ]
That's exactly what it already does ofcourse ;-)
If the array entry is NULL, just update it with a pointer to the CFI. If it's not NULL, make sure it matches the existing CFI, and WARN if it doesn't. Also, with this data structure, the ORC generation should also be a lot more straightforward, just ignore the NULL entries.
Yeah, I suppose it gets rid of the memcmp-prev thing.
Thoughts? This is all theoretical of course, I could try to do a patch tomorrow.
No real objection, I just didn't do it because 1) it works, and 2) even moar lines.