Re: [PATCH] Add VDSO time function support for x86 32-bit kernel

From: Andy Lutomirski <luto@amacapital.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: criu@openvz.org, Stefani Seibold <stefani@seibold.net>,
	linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, ak@linux.intel.com, aarcange@redhat.com,
	john.stultz@linaro.org
Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel
Date: Thu, 13 Dec 2012 18:20:00 -0800	[thread overview]
Message-ID: <CALCETrX5KUiQaV7dsAFa1SYyWPjUVwh43HvbPwqPStMxqE0ctQ@mail.gmail.com> (raw)
In-Reply-To: <8c3585bc-fc7d-4826-913c-f4581494d91d@email.android.com>

On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Wouldn't the vdso get mapped already and could be mremap()'d.  If we really need more control I'd almost push for a device/filesystem node that could be mmapped the usual way.

Hmm.  That may work, but it'll still break ABI.  I'm not sure that
criu is stable enough yet that we should care.  Criu people?

(In brief summary: how annoying would it be if the vdso was no longer
just a bunch of constant bytes that lived somewhere?)

--Andy

>
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>>On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 12/13/2012 05:42 PM, Andy Lutomirski wrote:
>>>>
>>>> The 64-bit/x32 case is currently very simple and fast because it
>>uses
>>>> absolute addressing.  Admittedly, pcrel references are free, so
>>>> changing this wouldn't cost much.  For native, it'll be slower, but
>>>> maybe no one cares.  I seem to care about this more than anyone
>>else,
>>>> and I don't use 32 bit code. :)
>>>>
>>>
>>> pcrel is actually cheaper than absolute addressing in 64-bit mode.
>>>
>>>> The benefit of switching is that the vdso code could be the same in
>>>> all three cases.  (Actually, it's even better than that.  All of the
>>>> VVAR magic could be the same in the vdso and the kernel -- the
>>kernel
>>>> linker script would just have to have an appropriate symbol to see
>>the
>>>> appropriate mapping.)
>>>>
>>>>
>>>> This:
>>>>
>>>> __attribute__((visibility("hidden"))) int foo;
>>>>
>>>> int get_foo(void)
>>>> {
>>>>   return foo;
>>>> }
>>>>
>>>> generates a rip-relative access on 64 bits and GOTOFF on 32 bits.
>>>>
>>>> The only reason I didn't use a real symbol in the first place is
>>>> because I couldn't figure out how to get gcc to emit an absolute
>>>> relocation in pic code.
>>>
>>> Well, then, we wouldn't need to do that... this is starting to sound
>>> like a significant win.
>>
>>How will this avoid breaking checkpoint/restore in userspace?  If the
>>vdso is not just plain old code, criu presumably needs to know about
>>it.  Should there be an arch_prctl(ARCH_MAP_VDSO, addr) to create a
>>vdso mapping somewhere?
>>
>>--Andy
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

-- 
Andy Lutomirski
AMA Capital Management, LLC