Message-ID: <AANLkTimPSQ3K6ulqGV243w__IbMaJTG71VckB8gl701u@mail.gmail.com>
Date:	Sat, 12 Jun 2010 15:34:38 +0200
From:	Paolo Giarrusso <p.giarrusso@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Borislav Petkov <bp@...en8.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Borislav Petkov <borislav.petkov@....com>,
	Toralf Förster <toralf.foerster@....de>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Jeff Dike <jdike@...toit.com>
Subject: Re: [uml-devel] [PATCH] x86, hweight: Fix UML boot crash

On Sun, May 30, 2010 at 23:09, H. Peter Anvin <hpa@...or.com> wrote:
> On 05/30/2010 01:17 PM, Borislav Petkov wrote:
>>>> This bothers me, because it really feels like something is fundamentally
>>>> broken in UML tryingto track the upstream architecture, and this is just
>>>> a bandage.
>>>
>>> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML
>>> special cases in x86 just because they include it.
>>>
>>> Which begs the question why _is_ UML sucking in x86 stuff and can anyone
>>> provide us with some sensible reasons? Because if there aren't any, it
>>> is their includes that should be fixed. Let me see what I can do to
>>> redirect hweight stuff properly...
>>
>> Ok, AFAICT UML is sucking in the includes of the sub-architecture the
>> UML "guest" is running on. See below¹ for the whole gcc string make
>> executes. Among the switches is
>>
>> "-I/home/boris/kernel/linux-2.6/arch/x86/include"
>>
>> so there will be no untangling today. Instead, we could do another
>> bandaid which is confined to UML include space only and redirect
>> arch_hweight.h includes to the generic ones. Check this out, it seems to
>> work here:
>>
>
> 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.

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.

Good bye!
-- 
Paolo Giarrusso - Ph.D. Student
http://www.informatik.uni-marburg.de/~pgiarrusso/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists