Re: [uml-devel] [PATCH] x86, hweight: Fix UML boot crash

[Borislav Petkov <bp@alien8.de>]

From: Paolo Giarrusso <p.giarrusso@gmail.com>
Date: Sat, Jun 12, 2010 at 03:34:38PM +0200

Hi,

> > That looks better to me, although I'm still wondering why UML can't
> > stomach the register-saving tricks... it is not at all "obvious" why
> > that can't be done.
> Hi all, and sorry for the delay, I hope you still care about this.
> 
> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved
> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with
> UML), or copied in UML (it's not defined, as far as I can see).
> Otherwise it just can't work. And I think that's it.
> 
> Second, I've been looking at arch_hweight.h to try answering as well,
> and my question is: did somebody ever implement ALTERNATIVE support on
> UML? When I worked on it, this thing didn't exist at all. The user
> declared the host CPU, and we enabled features based on that. There's
> barely code for exception tables, and we never used it to implement
> copy_from_user and staff like that (I recall the exception handler was
> set at run-time).
> 
> Indeed, arch/um/kernel/um_arch.c:apply_alternatives() is empty. And I
> mean, implementing it is not so trivial (unlike exception handling),
> simply because it requires making the binary mapping writable, and I'm
> not sure UML does it already.

Which would mean that UML doesn't use alternatives at all and uses the
instructions which are meant to be replaced instead, no? In that case,
fixing this is either by rerouting the includes (easiest, already in
-tip) or adding alternatives support (harder, needs volunteers :)).

> A third note is that UML links with glibc, so it can have a different
> calling convention from the kernel. Say, on x86 32bit regparm doesn't
> work (in fact, -mregparm is set in arch/x86/Makefile and not in
> arch/x86/Makefile_32.cpu). And since popcnt is supported on 32bit, it
> might in theory make a difference for that case. But maybe those flags
> are simply fine, I didn't recheck the possible calling conventions.

If this is also the case, the -fcall-saved-* stuff won't work on UML and
yet another way of doing "call *func" from within asm("...") and making
sure the callee doesn't clobber caller's regs will be needed for UML.

-- 
Regards/Gruss,
    Boris.