Re: [PATCH v4 2/7] um: enable the use of optimized xor routines in UML

[Johannes Berg <johannes@sipsolutions.net>]

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


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um