On 10/01/2014 07:31 PM, H. Peter Anvin wrote:
> On 09/10/2014 10:31 PM, Andrey Ryabinin wrote:
>> On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
>>> On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual
On 09/10/2014 10:31 PM, Andrey Ryabinin wrote:
> On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
>> On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
>>> This patch add arch specific code for kernel address sanitizer.
>>>
>>> 16TB of virtual addressed used for shadow memory.
>>> It's located in range
On 09/10/2014 10:31 PM, Andrey Ryabinin wrote:
On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range
On 10/01/2014 07:31 PM, H. Peter Anvin wrote:
On 09/10/2014 10:31 PM, Andrey Ryabinin wrote:
On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow
On 09/11/2014 07:51 AM, Andrey Ryabinin wrote:
> On 09/11/2014 08:29 AM, Sasha Levin wrote:
>> > On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>>> >> Except you just broke PVop kernels.
>> >
>> > So is this why v2 refuses to boot on my KVM guest? (was digging
>> > into that before I send a mail
On 09/11/2014 07:51 AM, Andrey Ryabinin wrote:
On 09/11/2014 08:29 AM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
Maybe
On 09/11/2014 08:29 AM, Sasha Levin wrote:
> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>> Except you just broke PVop kernels.
>
> So is this why v2 refuses to boot on my KVM guest? (was digging
> into that before I send a mail out).
>
Maybe this will help?
From: Andrey Ryabinin
Subject:
On 09/11/2014 08:29 AM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
Maybe this will help?
From: Andrey Ryabinin
On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
> On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
>> This patch add arch specific code for kernel address sanitizer.
>>
>> 16TB of virtual addressed used for shadow memory.
>> It's located in range [0x8000 - 0x9000]
>> Therefore
On 09/11/2014 08:46 AM, Andi Kleen wrote:
> On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
>> On 09/10/2014 09:29 PM, Sasha Levin wrote:
>>> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
>>>
>>> So is this why v2 refuses to boot on my KVM
On 09/10/2014 09:46 PM, Andi Kleen wrote:
> On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
>> On 09/10/2014 09:29 PM, Sasha Levin wrote:
>>> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
>>>
>>> So is this why v2 refuses to boot on my KVM
On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
> On 09/10/2014 09:29 PM, Sasha Levin wrote:
> > On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
> >> Except you just broke PVop kernels.
> >
> > So is this why v2 refuses to boot on my KVM guest? (was digging
> > into that before I
On 09/10/2014 09:29 PM, Sasha Levin wrote:
> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>> Except you just broke PVop kernels.
>
> So is this why v2 refuses to boot on my KVM guest? (was digging
> into that before I send a mail out).
>
No, KVM should be fine. It is Xen PV which ends up as a
On 09/10/2014 09:29 PM, Sasha Levin wrote:
> On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
>> Except you just broke PVop kernels.
>
> So is this why v2 refuses to boot on my KVM guest? (was digging
> into that before I send a mail out).
>
No, KVM should be fine. It is Xen PV which ends up as a
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
> Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Except you just broke PVop kernels.
Sent from my tablet, pardon any formatting problems.
> On Sep 10, 2014, at 15:45, Dave Hansen wrote:
>
>> On 09/10/2014 01:30 PM, Andrey Ryabinin wrote:
>> Yes, there is a reason for this. For inline instrumentation we need to
>> catch access to userspace
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> This patch add arch specific code for kernel address sanitizer.
>
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0x8000 - 0x9000]
> Therefore PAGE_OFFSET has to be changed from
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> This patch add arch specific code for kernel address sanitizer.
>
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0x8000 - 0x9000]
> Therefore PAGE_OFFSET has to be changed from
On 09/10/2014 01:30 PM, Andrey Ryabinin wrote:
> Yes, there is a reason for this. For inline instrumentation we need to
> catch access to userspace without any additional check.
> This means that we need shadow of 1 << 61 bytes and we don't have so
> many addresses available.
That sounds
2014-09-10 19:46 GMT+04:00 Dave Hansen :
> Overall, the approach here looks pretty sane. As you noted, it would be
> nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
> me. The use of the vmemmap code looks to be a nice fit.
>
> Few nits below.
>
> On 09/10/2014 07:31 AM,
Overall, the approach here looks pretty sane. As you noted, it would be
nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
me. The use of the vmemmap code looks to be a nice fit.
Few nits below.
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> 16TB of virtual addressed used
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range [0x8000 - 0x9000]
Therefore PAGE_OFFSET has to be changed from 0x8800
to 0x9000.
At early stage we map whole
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range [0x8000 - 0x9000]
Therefore PAGE_OFFSET has to be changed from 0x8800
to 0x9000.
At early stage we map whole
Overall, the approach here looks pretty sane. As you noted, it would be
nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
me. The use of the vmemmap code looks to be a nice fit.
Few nits below.
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
16TB of virtual addressed used
2014-09-10 19:46 GMT+04:00 Dave Hansen dave.han...@intel.com:
Overall, the approach here looks pretty sane. As you noted, it would be
nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
me. The use of the vmemmap code looks to be a nice fit.
Few nits below.
On
On 09/10/2014 01:30 PM, Andrey Ryabinin wrote:
Yes, there is a reason for this. For inline instrumentation we need to
catch access to userspace without any additional check.
This means that we need shadow of 1 61 bytes and we don't have so
many addresses available.
That sounds reasonable.
--
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range [0x8000 - 0x9000]
Therefore PAGE_OFFSET has to be changed from 0x8800
to
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range [0x8000 - 0x9000]
Therefore PAGE_OFFSET has to be changed from 0x8800
to
Except you just broke PVop kernels.
Sent from my tablet, pardon any formatting problems.
On Sep 10, 2014, at 15:45, Dave Hansen dave.han...@intel.com wrote:
On 09/10/2014 01:30 PM, Andrey Ryabinin wrote:
Yes, there is a reason for this. For inline instrumentation we need to
catch access to
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 09/10/2014 09:29 PM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
No, KVM should be fine. It is Xen PV which ends up as a
On 09/10/2014 09:29 PM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail out).
No, KVM should be fine. It is Xen PV which ends up as a
On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
On 09/10/2014 09:29 PM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was digging
into that before I send a mail
On 09/10/2014 09:46 PM, Andi Kleen wrote:
On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
On 09/10/2014 09:29 PM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was
On 09/11/2014 08:46 AM, Andi Kleen wrote:
On Wed, Sep 10, 2014 at 09:33:11PM -0700, H. Peter Anvin wrote:
On 09/10/2014 09:29 PM, Sasha Levin wrote:
On 09/11/2014 12:26 AM, H. Peter Anvin wrote:
Except you just broke PVop kernels.
So is this why v2 refuses to boot on my KVM guest? (was
On 09/11/2014 08:01 AM, H. Peter Anvin wrote:
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
This patch add arch specific code for kernel address sanitizer.
16TB of virtual addressed used for shadow memory.
It's located in range [0x8000 - 0x9000]
Therefore PAGE_OFFSET
36 matches
Mail list logo
