Message-ID: <1355862759.28056.14.camel@wall-e>
Date:	Tue, 18 Dec 2012 21:32:39 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	mingo@...hat.com, ak@...ux.intel.com, aarcange@...hat.com,
	john.stultz@...aro.org, luto@...capital.net, xemul@...allels.com,
	gorcunov@...nvz.org, andriy.shevchenko@...ux.intel.com
Subject: Re: [PATCH 6/6] Add 32 bit VDSO support for 32 and 64 bit kernels

Am Dienstag, den 18.12.2012, 10:44 -0800 schrieb H. Peter Anvin:
> On 12/18/2012 08:52 AM, Stefani Seibold wrote:
> > 
> > Pardon, i never disregarded nor i have agreed that this is going to be a
> > part of the VDSO. I currently have also no idea how to do this and i see
> > no need at the moment to do this revamp. The 64 bit VDSO lives since
> > more than 6 years with this kind of implementation.
> > 
> 
> It was part of this discussion thread, about how to best manage the
> address space.  Fixed addresses are a major problem, and introducing new
> ones are extremely undesirable.
> 

There is no introduce of new fix address. There are still there for
x86_64. If this will currently not a major problem on this architecture
than it will not for x86_32 too.

> Hence I wrote:
> 
> > IMO it seems this is making it way more complicated than it is. Just
> > make sure you have a section in the vdso where you can map in a data
> > page with the symbols in the right offsets. Extra points for doing
> > magic so that it is at the beginning or end, but I think that might
> > be harder than necessary.
> 
> Basically, make the vvar and hpet pages part of the vdso page list.
> Optionally they can be mapped without the MAYWRITE option -- in fact, we
> could easily split the vdso into an executable area which gets MAYWRITE
> to be able to set breakpoints and a data area which doesn't -- but that
> is a minor tweak IMO.
> 

I see the benefits, but it will not work under all circumstance. The
VDSO compat mode for x86_32 requires a fix address and there is no room
behind this. So since this must preserved, i see no real gain for this.

> > You asked me to do the VDSO 32 bit stuff for the IA32_EMULATION, before
> > it is ready for inclusion into the kernel. Thats exactly what i did. I
> > spend the whole weekend of my spare time to do this implementation. Now
> > we have them all.
> > 
> > The patch works perfectly, all issues are solved:
> > 
> > - Calling conventions
> > - ABI transformations
> > - System call gateway for X86 32 bit
> > - Mapping of the FIXMAP and HPET into the lower 32 bit address space for
> > IA32_EMULATION
> > - Support for 32 bit programs in 32 kernel and 64 bit kernel
> > - One VDSO source for all
> > 
> > If you prefer an other solutions, its okay. There are many ways to code
> > things. But for now i think it is a good step ahead. That is what i
> > currently can provide.
> 
> This is good.  We have some time anyway to get this ready for the 3.9
> merge window.
> 

What does this mean? Do you accept my patch or drop it? I see no real
technical issue to drop it. It makes things better not worse. Maybe
there is a better solution, but this is the next step.

I advocate to apply this patch, because i spend a lot time to write it
and it is a good base to continue the work.

- Stefani


--
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