From: Stefani Seibold <stefani@seibold.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Greg KH <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
John Stultz <john.stultz@linaro.org>,
Pavel Emelyanov <xemul@parallels.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
andriy.shevchenko@linux.intel.com,
Martin.Runge@rohde-schwarz.com, Andreas.Brief@rohde-schwarz.com
Subject: Re: [PATCH 4/4] Add 32 bit VDSO support for 64 kernel
Date: Thu, 30 Jan 2014 20:43:13 +0100 [thread overview]
Message-ID: <1391110993.945.19.camel@wall-e.seibold.net> (raw)
In-Reply-To: <CALCETrXMPkA3ZfwGo8iQQDL=7HXBE3Mo8j6Zi+bTu=eoL-b43w@mail.gmail.com>
Am Donnerstag, den 30.01.2014, 10:21 -0800 schrieb Andy Lutomirski:
> On Thu, Jan 30, 2014 at 2:49 AM, <stefani@seibold.net> wrote:
> > From: Stefani Seibold <stefani@seibold.net>
> >
> > This patch add the support for the IA32 Emulation Layer to run 32 bit
> > applications on a 64 bit kernel.
> >
> > Due the nature of the kernel headers and the LP64 compiler where the
> > size of a long and a pointer differs against a 32 bit compiler, there
> > is a lot of type hacking necessary.
> >
> > This kind of type hacking could be prevent in the future by doing a call to the
> > 64 bit code by the following sequence:
> >
> > - Compile the arch/x86/vdso/vclock_gettime.c as 64 bit, but only generate
> > the assemble output.
> > - Next compile a 32 bit object by including the 64 bit vclock_gettime.s
> > prefixed with .code64
> > - At least we need a trampolin code which invokes the 64 bit code and do
> > the API conversation (64 bit longs to 32 bit longs), like the
> > followig snipped:
> >
> > ENTRY(call64)
> > push %ebp
> > movl %esp, %ebp
> > ljmp $__USER_CS, $1f
> > .code64
>
> I bet that this trampoline takes at least as long as a syscall /
> sysenter instruction. I'd be surprised if designers of modern cpus
> care at all about ljmp latency.
>
I have no idea, this must be measured. The code is smaller and it would
save a lot of compaility issues.
>
> >
> > Signed-off-by: Stefani Seibold <stefani@seibold.net>
> > ---
> > arch/x86/vdso/vclock_gettime.c | 112 ++++++++++++++++++++++++++--------
> > arch/x86/vdso/vdso32/vclock_gettime.c | 7 +++
> > 2 files changed, 95 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
> > index 19b2a49..a2417e2 100644
> > --- a/arch/x86/vdso/vclock_gettime.c
> > +++ b/arch/x86/vdso/vclock_gettime.c
> > @@ -31,12 +31,24 @@
> >
> > #define gtod (&VVAR(vsyscall_gtod_data))
> >
> > +struct api_timeval {
> > + long tv_sec; /* seconds */
> > + long tv_usec; /* microseconds */
> > +};
> > +
> > +struct api_timespec {
> > + long tv_sec; /* seconds */
> > + long tv_nsec; /* microseconds */
> > +};
> > +
> > +typedef long api_time_t;
> > +
> > static notrace cycle_t vread_hpet(void)
> > {
> > return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + HPET_COUNTER);
> > }
> >
> > -notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
> > +notrace static long vdso_fallback_gettime(long clock, struct api_timespec *ts)
> > {
> > long ret;
> > asm("syscall" : "=a" (ret) :
> > @@ -44,7 +56,8 @@ notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
> > return ret;
> > }
> >
> > -notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
> > +notrace static long vdso_fallback_gtod(struct api_timeval *tv,
> > + struct timezone *tz)
> > {
> > long ret;
> >
> > @@ -54,20 +67,68 @@ notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
> > }
> > #else
> >
> > +#ifdef CONFIG_IA32_EMULATION
> > +typedef s64 arch_time_t;
> > +
> > +struct arch_timespec {
> > + s64 tv_sec;
> > + s64 tv_nsec;
> > +};
> > +
> > +#define ALIGN8 __attribute__ ((aligned (8)))
> > +
> > +struct arch_vsyscall_gtod_data {
> > + seqcount_t seq ALIGN8;
> > +
> > + struct { /* extract of a clocksource struct */
> > + int vclock_mode ALIGN8;
> > + cycle_t cycle_last ALIGN8;
> > + cycle_t mask ALIGN8;
> > + u32 mult;
> > + u32 shift;
> > + } clock;
> > +
> > + /* open coded 'struct timespec' */
> > + arch_time_t wall_time_sec;
> > + u64 wall_time_snsec;
> > + u64 monotonic_time_snsec;
> > + arch_time_t monotonic_time_sec;
> > +
> > + struct timezone sys_tz;
> > + struct arch_timespec wall_time_coarse;
> > + struct arch_timespec monotonic_time_coarse;
> > +};
>
> Yuck!
>
> Can you see how hard it would be to just make the real gtod data have
> the same layout for 32-bit and 64-bit code?
>
It is not easy, because the there are a lot of data types which use
longs (struct timespec, time_t) and seqcount has a variable size
depending on the kernel configuration.
next prev parent reply other threads:[~2014-01-30 19:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-30 10:49 [PATCH 0/4] Add 32 bit VDSO time function support stefani
2014-01-30 10:49 ` [PATCH 1/4] Make vsyscall_gtod_data handling x86 generic stefani
2014-01-30 18:05 ` Andy Lutomirski
2014-01-30 19:27 ` Stefani Seibold
2014-01-30 19:51 ` Andy Lutomirski
2014-01-30 20:19 ` Stefani Seibold
2014-01-31 0:10 ` Andi Kleen
2014-02-01 14:51 ` Stefani Seibold
2014-01-30 10:49 ` [PATCH 2/4] Add new func _install_special_mapping() to mmap.c stefani
2014-01-30 10:49 ` [PATCH 3/4] Add 32 bit VDSO support for 32 kernel stefani
2014-01-30 15:30 ` H. Peter Anvin
2014-01-30 15:53 ` Stefani Seibold
2014-01-30 18:17 ` Andy Lutomirski
2014-01-30 19:39 ` Stefani Seibold
2014-01-30 19:50 ` Andy Lutomirski
2014-01-30 10:49 ` [PATCH 4/4] Add 32 bit VDSO support for 64 kernel stefani
2014-01-30 18:21 ` Andy Lutomirski
2014-01-30 19:43 ` Stefani Seibold [this message]
2014-01-31 23:12 ` Andy Lutomirski
2014-01-30 15:31 ` [PATCH 0/4] Add 32 bit VDSO time function support H. Peter Anvin
2014-01-30 15:52 ` Stefani Seibold
2014-01-30 15:54 ` H. Peter Anvin
2014-01-30 17:57 ` Andy Lutomirski
2014-01-30 18:03 ` H. Peter Anvin
2014-01-30 18:08 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1391110993.945.19.camel@wall-e.seibold.net \
--to=stefani@seibold.net \
--cc=Andreas.Brief@rohde-schwarz.com \
--cc=Martin.Runge@rohde-schwarz.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gorcunov@openvz.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome