[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230627042538.GAZJpkwldpkqTKeeDL@fat_crate.local>
Date: Tue, 27 Jun 2023 06:25:38 +0200
From: Borislav Petkov <bp@...en8.de>
To: Dave Hansen <dave.hansen@...el.com>,
Richard Weinberger <richard@....at>
Cc: Sebastian Sumpf <Sebastian.Sumpf@...ode-labs.com>,
tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [Bug report] __arch_hweight32/64 x86
On Mon, Jun 26, 2023 at 03:41:27PM -0700, Dave Hansen wrote:
> I'm not even sure that UML needs GENERIC_HWEIGHT. From a quick glance,
> it looks like x86 used to use GENERIC_HWEIGHT, but got arch-specific
> versions later. UML just never moved over to the arch-specific versions.
Thanks - that could very well be the explanation.
That bug report made me blink a couple of times since I did take extra
precaution to not clobber regs in arch/x86/lib/hweight.S as this was
part of the whole pain back then with calling a function from asm where
gcc doesn't even know we're calling a function, see:
f5967101e9de ("x86/hweight: Get rid of the special calling convention")
> I _think_ the attached patch might just fix the problems with the C
> version and bring the x86/UML implementation back in line with the rest
> of x86.
>
> Thoughts?
> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> index 186f13268401..76d507860be4 100644
> --- a/arch/x86/um/Kconfig
> +++ b/arch/x86/um/Kconfig
> @@ -44,6 +44,3 @@ config ARCH_HAS_SC_SIGNALS
>
> config ARCH_REUSE_HOST_VSYSCALL_AREA
> def_bool !64BIT
> -
> -config GENERIC_HWEIGHT
> - def_bool y
Yeah, we should do it. UML should not do anything different wrt calling
conventions so it should be able to handle the arch/x86/lib/hweight.S
versions just fine.
Richi?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists