On 12/17/2012 10:56 AM, Pavel Emelyanov wrote:
> On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
>> Because it is almost impossible to do right?
>
> In the generic case -- I tend to agree. But it's possible to describe
> how a library should communicate to crtools to make it possible.
>
> Anyway, w
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
> Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I wanted to say -- we didn't have this scenario in our
p
Because it is almost impossible to do right?
Pavel Emelyanov wrote:
>On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
>> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin
>wrote:
>>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> On Thu, De
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> Wouldn't the vdso get map
On 12/14/2012 03:48 PM, John Stultz wrote:
> On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
>> On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
>>> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>>>
>>>
>>> This won't help in case of scenario you've been pointing in
>>> previous email
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r happens in a middle of vdso),
would it? Because we
On 12/14/2012 03:09 PM, Stefani Seibold wrote:
>
> Sorry for not following the discussion, but im am currently trying to
> compile the vclocktime.c as a 32 bit object. Most of the (clever) work
> is done.
>
> After this the next step is to map the needed fixmaps into the 32 bit
> address space. M
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> > On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> >> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> >>> Wouldn't the vdso get mapped already and could be mremap()'d. If we
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>>>
>>> this would allow us to defer checkpoint until task finish vdso code. Peter,
>>> if I understand you correctly you propose we pro
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin 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 nod
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
> >
> > this would allow us to defer checkpoint until task finish vdso code. Peter,
> > if I understand you correctly you propose we provide some own proxy-vdso
> > which would redirect
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>
> this would allow us to defer checkpoint until task finish vdso code. Peter,
> if I understand you correctly you propose we provide some own proxy-vdso
> which would redirect calls to real ones, right? But the main problem
> is that is exactly the
On Fri, Dec 14, 2012 at 02:00:17PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
> >
> > I don't know all that much about the linux vm. Can we create a
> > special vdso address_space or struct inode or something so that a
> > single vma can contain pages with diffe
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
>
> I don't know all that much about the linux vm. Can we create a
> special vdso address_space or struct inode or something so that a
> single vma can contain pages with different flags?
>
No, that is still different vmas, but it probably isn't a
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>> The real issue is that happens if the process is checkpointed while
>>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>>> This is not impossible or even unlikel
On 12/14/2012 01:20 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame poi
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
> >>>
> >> The real issue is that happens if the process is checkpointed while
> >> inside the vdso and now eip/rip or a stack frame points into the vdso.
> >> This is not impossible or
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>>
>> The real issue is that happens if the process is checkpointed while
>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>> This is not impossible or even unlikely, especially on 32 bits it is
>> downright likely.
>
> I fea
On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
> On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
> >>
> >> mremap() should work. At the same time, the code itself is not going to
> >> have any stability guarantees between kernel versions -- it obviously
> >> cannot.
> >
> > We cou
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
>>
>> mremap() should work. At the same time, the code itself is not going to
>> have any stability guarantees between kernel versions -- it obviously
>> cannot.
>
> We could guarantee that the symbols in the vdso resolve to particular
> offsets with
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
Wouldn't the vdso get mapped already and could be mremap()'d. If we
>>> reall
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin 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 nod
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin 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.
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin 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 s
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.
Andy Lutomirski wrote:
>On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin wrote:
>> On 12/13/2012 05:42 PM, Andy Lutomi
On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin 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, i
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 abo
On Thu, Dec 13, 2012 at 5:32 PM, H. Peter Anvin wrote:
> On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
>>
>>
>> What you could do is probably arrange (using some linker script magic)
>> for a symbol to exist that points at the page *before* the vdso
>> starts. Then just map the vvar page there w
On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
What you could do is probably arrange (using some linker script magic)
for a symbol to exist that points at the page *before* the vdso
starts. Then just map the vvar page there when starting a compat
task. You could then address it using a normal
On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
Whatever data you need you can just map it into the vdso range. There
really shouldn't be anything special about that at all.
The fixmap stuff is an x86-64 legacy that you don't have to worry about,
obviously.
The fixmap page is new. It's not A
On Thu, Dec 13, 2012 at 4:09 PM, H. Peter Anvin wrote:
> On 12/13/2012 11:32 AM, Andy Lutomirski wrote:
>>
>>
>> x32's vdso cheats -- x32 code can see high addresses just fine. The
>> toolchain just makes it difficult.
>>
>> Your best bet is probably to just map the vvar page twice -- once at
>>
On 12/13/2012 11:32 AM, Andy Lutomirski wrote:
x32's vdso cheats -- x32 code can see high addresses just fine. The
toolchain just makes it difficult.
Your best bet is probably to just map the vvar page twice -- once at
the same address as native 32-bit mode (but only for compat tasks)
would us
On Wed, Dec 12, 2012 at 11:17 PM, Stefani Seibold wrote:
> Am Mittwoch, den 12.12.2012, 22:47 -0800 schrieb H. Peter Anvin:
>> Should be a simple matter of sharing pages. Look perhaps at the x32 vdso
>> for a hint.
>>
>
>
>> >
>> >Any idea or clean solution how i can map the 64 bit vgtod into th
Am Mittwoch, den 12.12.2012, 22:47 -0800 schrieb H. Peter Anvin:
> Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for
> a hint.
>
> >
> >Any idea or clean solution how i can map the 64 bit vgtod into the 32
> >bit address space? Thats the only problem i see.
> >
No,
Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for a
hint.
Stefani Seibold wrote:
>Am Mittwoch, den 12.12.2012, 22:14 -0800 schrieb H. Peter Anvin:
>> This is too late for 3.8 anyway, so there is time to make it work
>correctly before tge 3.9 merge window anyway. Aft
Am Mittwoch, den 12.12.2012, 22:14 -0800 schrieb H. Peter Anvin:
> This is too late for 3.8 anyway, so there is time to make it work correctly
> before tge 3.9 merge window anyway. After this merge window is over I may
> pull tjis into a testing branch, but compat support is a precondition.
>
>
This is too late for 3.8 anyway, so there is time to make it work correctly
before tge 3.9 merge window anyway. After this merge window is over I may pull
tjis into a testing branch, but compat support is a precondition.
The vdso is only optional if you build in backwards compatibility anyway,
No, let's not. Why? Because if we do that we may inadvertently create an ABI
which is hard to support across the board.
Stefani Seibold wrote:
>Am Mittwoch, den 12.12.2012, 15:34 -0800 schrieb H. Peter Anvin:
>> On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
>> > diff --git a/arch/x86/vds
Am Mittwoch, den 12.12.2012, 15:34 -0800 schrieb H. Peter Anvin:
> On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
> > diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
> > b/arch/x86/vdso/vdso32/vclock_gettime.c
> > new file mode 100644
> > index 000..c9a1909
> > --- /dev/null
> > +++ b/a
On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
b/arch/x86/vdso/vdso32/vclock_gettime.c
new file mode 100644
index 000..c9a1909
--- /dev/null
+++ b/arch/x86/vdso/vdso32/vclock_gettime.c
@@ -0,0 +1,7 @@
+/*
+ * since vgtod layout differs b
From: Stefani Seibold
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86 32-bit kernels.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time time stamp, without knowing the
[cc: Jeremy Fitzhardinge -- you wrote some of this]
On Tue, Dec 11, 2012 at 12:40 PM, Stefani Seibold wrote:
> Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
>> On Tue, Dec 11, 2012 at 8:11 AM, wrote:
>> > --- a/arch/x86/vdso/vclock_gettime.c
>> > +++ b/arch/x86/vdso/vclock_g
Am Dienstag, den 11.12.2012, 13:18 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold wrote:
> > Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> >> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> >> > From: Stefani Seibold
> >> >
> >> > This sm
On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold wrote:
> Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
>> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
>> > From: Stefani Seibold
>> >
>> > This small patch add the functions vdso_gettimeofday(),
>> > vdso_clock_gettime()
>>
Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86 32-bit kernels.
> >
> >
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 8:11 AM, wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86 32-bit kernels.
> >
> > The r
On Tue, Dec 11, 2012 at 11:27 AM, John Stultz wrote:
> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
>>
>> From: Stefani Seibold
>>
>> This small patch add the functions vdso_gettimeofday(),
>> vdso_clock_gettime()
>> and vdso_time() support to the VDSO for x86 32-bit kernels.
>>
>> The reas
On Tue, Dec 11, 2012 at 8:11 AM, wrote:
> From: Stefani Seibold
>
> This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> and vdso_time() support to the VDSO for x86 32-bit kernels.
>
> The reason to do this was to get a fast reliable time stamp. Many developers
> uses T
On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86 32-bit kernels.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TS
From: Stefani Seibold
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86 32-bit kernels.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time time stamp, without knowing the
50 matches
Mail list logo
