Thread (14 messages) 14 messages, 3 authors, 2020-12-16

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help