* Linus Torvalds wrote:
> On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
> wrote:
> >
> > If the only immediate problem is the code generation size, then Andy
> > already had a (simpler) hack-around:
> >
> > #undef CONFIG_OPTIMIZE_INLINING
> > #undef CONFIG_X86_PPRO_FENCE
> >
> > in vclock
On 03/10/2014 02:29 PM, stef...@seibold.net wrote:
>
> Do you except a complete new patch set or an incremental patch based on the
> current patch set?
>
An incremental patch is probably easier.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On 03/10/2014 02:39 PM, Linus Torvalds wrote:
> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>>
>> This was discovered by me.
>
> Sorry for the misattribution.
>
>> But this is not a real solution, at least when vcpu function support
>> will be added, then the code size will exceed the page size. Re
On 03/10/2014 02:51 PM, Dave Jones wrote:
>
> Even when it worked, it was only a small performance increase anyway,
>
If it is performance rather then correctness, then let's kill it now.
I'd love to push that patchset already for 3.15, anyone want to write it
up (I'm on a trip)... otherwise I'
On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski wrote:
> On Mon, Mar 10, 2014 at 2:53 PM, wrote:
>> Zitat von Linus Torvalds :
>>
>>> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
This was discovered by me.
>>>
>>>
>>> Sorry for the misattribution.
>>>
But this is not a real sol
On Mon, Mar 10, 2014 at 2:53 PM, wrote:
> Zitat von Linus Torvalds :
>
>> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>>>
>>>
>>> This was discovered by me.
>>
>>
>> Sorry for the misattribution.
>>
>>> But this is not a real solution, at least when vcpu function support
>>> will be added, then the
Zitat von Linus Torvalds :
On Mon, Mar 10, 2014 at 2:25 PM, wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed the page size. Reserving
two pages for the VDSO i
On Mon, Mar 10, 2014 at 02:20:34PM -0700, Linus Torvalds wrote:
> I also suspect we should get rid of CONFIG_X86_OOSTORE, or at least
> limit it to !SMP - I don't think anybody ever made SMP systems with
> those IDT/Centaur Winchip chips in them.
Given the number of people who ever used that c
On Mon, Mar 10, 2014 at 2:20 PM, Linus Torvalds
wrote:
> On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
> wrote:
>>
>> If the only immediate problem is the code generation size, then Andy
>> already had a (simpler) hack-around:
>>
>> #undef CONFIG_OPTIMIZE_INLINING
>> #undef CONFIG_X86_PPRO_
On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>
> This was discovered by me.
Sorry for the misattribution.
> But this is not a real solution, at least when vcpu function support
> will be added, then the code size will exceed the page size. Reserving
> two pages for the VDSO is a good option.
Quite
Zitat von "H. Peter Anvin" :
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
What is now the next step? Kick out the compat VDSO? Or should i
implement the dual VDSO. And what is now the preferred way to map the
VDSO into the user space? Using install_special_mapping() or map it
beyond the use
Zitat von Linus Torvalds :
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin wrote:
The quick way to get something working is simply to reserve more than
one page (two should presumably be enough) in the fixmap and adjust the
link address of the VDSO accordingly. This is not where we want to
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
wrote:
>
> If the only immediate problem is the code generation size, then Andy
> already had a (simpler) hack-around:
>
> #undef CONFIG_OPTIMIZE_INLINING
> #undef CONFIG_X86_PPRO_FENCE
>
> in vclock_gettime.c
Btw, we should seriously consider g
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin wrote:
>
> The quick way to get something working is simply to reserve more than
> one page (two should presumably be enough) in the fixmap and adjust the
> link address of the VDSO accordingly. This is not where we want to go
> in the long term, bu
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
>
> What is now the next step? Kick out the compat VDSO? Or should i
> implement the dual VDSO. And what is now the preferred way to map the
> VDSO into the user space? Using install_special_mapping() or map it
> beyond the user stack?
>
> The is eas
Am Montag, den 10.03.2014, 10:12 -0700 schrieb Andy Lutomirski:
> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
> wrote:
> >
> > On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
> >>
> >> I have mentioned in the past wanting to move the fixmap to the low part
> >> of the kernel space, because t
On Sun, Mar 09, 2014 at 05:00:31PM -0700, H. Peter Anvin wrote:
> On 03/09/2014 12:08 AM, Stefani Seibold wrote:
> >
> > This was not addressed to you, it was addressed to the x86 intel kernel
> > developers to do more testing, since this piece of code has so many side
> > effects. I apologizes th
On Mon, Mar 10, 2014 at 10:58 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
>>>
>>> Hint: where is your RIP? Where is the RIP of other processes?
>>>
>>
>> Whoa there, I'm not suggesting anything nearly that crazy :)
>>
>> I'm suggesting changing out the vvar page *fo
On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
>>
>> Hint: where is your RIP? Where is the RIP of other processes?
>>
>
> Whoa there, I'm not suggesting anything nearly that crazy :)
>
> I'm suggesting changing out the vvar page *for that process*, which is
> not executable. The actual vdso cod
On Mon, Mar 10, 2014 at 10:48 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>>>
>>> Yes, we'd have to switch the vdso to using syscall access. Doing that
>>> from inside a system call is... "interesting".
>>
>> It's a little less interesting if it just involves changi
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>
> It might be nice in general for there to be a /dev/vdso and for the
> vdso to literally be a mapping of that device node. I bet that CRIU
> would appreciate this. (The mmap flags would be a little odd, since
> different pages have different prot
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>>
>> Yes, we'd have to switch the vdso to using syscall access. Doing that
>> from inside a system call is... "interesting".
>
> It's a little less interesting if it just involves changing a vma.
> It's still tricky, though -- would each struct mm h
On Mon, Mar 10, 2014 at 10:38 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
>>>
For 64-bit, this is an entirely different story. The vsyscall page is
stuck in the fixmap forever, although I want to add a way for
userspace to opt out. The vvar page, hpe
On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
>>
>>> For 64-bit, this is an entirely different story. The vsyscall page is
>>> stuck in the fixmap forever, although I want to add a way for
>>> userspace to opt out. The vvar page, hpet, etc could move into vmas,
>>> though. I kind of want to do
On Mon, Mar 10, 2014 at 10:24 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
>> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
>> wrote:
>>>
>>> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
I have mentioned in the past wanting to move the fixmap to the
On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
> wrote:
>>
>> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
>>>
>>> I have mentioned in the past wanting to move the fixmap to the low part
>>> of the kernel space, because the top isn't really fi
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
wrote:
>
> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
>>
>> I have mentioned in the past wanting to move the fixmap to the low part
>> of the kernel space, because the top isn't really fixed...
>
> How about the high part of the user address s
On 03/09/2014 09:46 PM, Andy Lutomirski wrote:
> On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski wrote:
>> (Of course, I haven't the faintest idea what l_addr in glibc means.
>> If there was a way to arrange for l_addr to be zero, then maybe none
>> of this would matter. Hmm, I wonder if just not
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski wrote:
> (Of course, I haven't the faintest idea what l_addr in glibc means.
> If there was a way to arrange for l_addr to be zero, then maybe none
> of this would matter. Hmm, I wonder if just not relocating the vdso
> at all would have the desired
On Sun, Mar 9, 2014 at 5:16 PM, H. Peter Anvin wrote:
> On 03/09/2014 12:47 AM, Stefani Seibold wrote:
>>
>> But let me ask an other question: Is the compat mode still needed
>> anymore?
>>
>> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
>> the __FIXADDR_TOP, there is no
On 03/09/2014 12:47 AM, Stefani Seibold wrote:
>
> But let me ask an other question: Is the compat mode still needed
> anymore?
>
> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
> the __FIXADDR_TOP, there is no fix place for the VDSO page. Also in the
> 32 bit emulation
On 03/09/2014 12:08 AM, Stefani Seibold wrote:
>
> This was not addressed to you, it was addressed to the x86 intel kernel
> developers to do more testing, since this piece of code has so many side
> effects. I apologizes this miss understanding.
>
I think you're misunderstanding.
We cannot deb
Am Freitag, den 07.03.2014, 15:07 -0800 schrieb Andy Lutomirski:
> On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold wrote:
> >
> > Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> >> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold
> >> wrote:
> >> > Hi Fengguang,
> >> >
> >> >
Am Samstag, den 08.03.2014, 07:44 +0800 schrieb Fengguang Wu:
> Hi Stefani,
>
> > So i tried my best, but without support it is impossible to find all
> > issues. But mostly what i get was bureaucracy afflictions
> >
> > I complied, but now it is time to help finding the issues. And not only
> >
Hi Stefani,
> So i tried my best, but without support it is impossible to find all
> issues. But mostly what i get was bureaucracy afflictions
>
> I complied, but now it is time to help finding the issues. And not only
> do a complain, sit back and wait.
I feel sorry if that's what you perceived
On 03/07/2014 08:06 AM, Stefani Seibold wrote:
>>
>> wfg@bee /tmp% git clone --reference /c/linux
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>
> As i wrote i already cloned the tip tree!!
>
> But i cannot see the changeset, there is also no VDSO changes set in the
> git log
On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold wrote:
>
> Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
>> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
>> > Hi Fengguang,
>> >
>> > i have build a kernel with the config, but my kvm is unable to start it.
>> > I will
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
> > Hi Fengguang,
> >
> > i have build a kernel with the config, but my kvm is unable to start it.
> > I will try to find a way to test your kernek config.
> >
> > One thing
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
> Hi Fengguang,
>
> i have build a kernel with the config, but my kvm is unable to start it.
> I will try to find a way to test your kernek config.
>
> One thing is the crash point:
>
> The function sysenter_setup was modified by Andy, maybe
Am Freitag, den 07.03.2014, 18:21 +0800 schrieb Fengguang Wu:
> Hi Stefani,
>
> On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
> > Hi Fengguang,
> >
> > did you test the config i had sent to you?
> >
> > My test was all done with current 3.14-rc tree. And with this i have no
>
Hi Stefani,
On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
> Hi Fengguang,
>
> did you test the config i had sent to you?
>
> My test was all done with current 3.14-rc tree. And with this i have no
> problem.
The regression is found on commit 4dea8e4824b363c53f320d328040d7c6c
Hi Fengguang,
did you test the config i had sent to you?
My test was all done with current 3.14-rc tree. And with this i have no
problem.
I just cloned the tip tree and i figured out that the patch was dropped
again (BTW: git log does not show that it was ever applied).
Okay, that's enough for
Hi Stefani,
On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
> Hi Fengguang,
>
> i was now able to bring up the kernel on my KVM with some minior
> changes. I kick out the PARIDE, switched to IDE and activated the VT
> support. With this modifications the kernel boot and i get no
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One thing is the crash point:
The function sysenter_setup was modified by Andy, maybe he has an idea
what fails.
- Stefani
Am Freitag, den 07.03.2014, 09:
44 matches
Mail list logo
