[PATCH v4 2/7] um: enable the use of optimized xor routines in UML
Johannes Berg
johannes at sipsolutions.net
Mon Dec 14 04:12:20 EST 2020
On Mon, 2020-12-14 at 09:07 +0000, Anton Ivanov wrote:
>
> I had a look at the alternatives processing in x86 once again. The
> exact definition of what we get to use is: "ancient, buggy CPUs in SMP
> mode".
fun.
> So in addition to using one of the worst case scenario
> implementations, we also do not do patching of SMP verbiage to UP
> where appropriate which is done on x86.
right.
> I just had a go at trying to reuse the aforementioned alternatives
> processing "as is" from the x86 tree.
>
> This is pretty much a no-go from the start. We can't use it. It relies
> on "owning" int handlers and generating int instructions in places. If
> I understand it correctly, it will interfere with gdb by doing its own
> INT 3 work. Key parts of it are also "if-defed away" from us at
> present.
>
> IMHO - it will have to be rewritten mostly from scratch for UML.
>
> I will have a look if we can reuse the cpu feature and bug definitions
> instead of using our own. This will allow us to reuse the bits which
> relate to crypto - xor, etc as those are cases/ifdefs instead of
> alternatives.
I agree.
But I feel like something I said sent you on this path, and that never
was my intent. I don't mind using the x86 header files in a fashion
similar to what you did, I just didn't like the symlinks because it
seems those would be awkward if somebody ever wants to port UML to some
other architecture ...
Maybe just put there header files with
#include "../../x86/include/asm/xor.h"
or something like that just to avoid the symlinks?
johannes
More information about the linux-um
mailing list