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

Anton Ivanov
2020-12-14T09:36:58Z

On 14/12/2020 09:12, Johannes Berg wrote:
> 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?

I agree with you - that is how we should use them.

We still need to have "features" code and boot time CPU detection.

I am trying to figure out if it is worth it to borrow some of that instead of my original hack which reused the names with a different back-end. That is another can of worms because some of that code is actually generated at compile time by x86 so I need to figure out how to pull that into our build system.

> johannes
>
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661