On 10/02/2013 11:48 AM, Frantisek Hrbata wrote:
>
> Ok, I can try to look into this. I just want to point out that some other
> archs
> like arm are doing it the same way. I simply replaced the generic check
> functions
> in drivers/char/mem.c with x86 specific ones.
>
I know. It is a
On Wed, Oct 02, 2013 at 11:36:09AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
> > On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> >> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> >>> +
> >>> +int valid_phys_addr_range(phys_addr_t addr,
On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
> On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
>> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
>>> +
>>> +int valid_phys_addr_range(phys_addr_t addr, size_t count)
>>> +{
>>> + return addr + count <= __pa(high_memory);
>>> +}
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> > +
> > +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> > +{
> > + return addr + count <= __pa(high_memory);
> > +}
> > +
> > +int valid_mmap_phys_addr_range(unsigned
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
> +
> +int valid_phys_addr_range(phys_addr_t addr, size_t count)
> +{
> + return addr + count <= __pa(high_memory);
> +}
> +
> +int valid_mmap_phys_addr_range(unsigned long pfn, size_t count)
> +{
> + resource_size_t addr = (pfn <<
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page [1] 4.5 IA-32e Paging: Table 4-19, bits 51-M(MAXPHYADDR)
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page [1] 4.5 IA-32e Paging: Table 4-19, bits 51-M(MAXPHYADDR)
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
+
+int valid_mmap_phys_addr_range(unsigned long pfn, size_t count)
+{
+ resource_size_t addr = (pfn PAGE_SHIFT) + count;
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
+
+int valid_mmap_phys_addr_range(unsigned long pfn, size_t
On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
+ return addr + count = __pa(high_memory);
+}
+
+int
On Wed, Oct 02, 2013 at 11:36:09AM -0700, H. Peter Anvin wrote:
On 10/02/2013 11:31 AM, Frantisek Hrbata wrote:
On Wed, Oct 02, 2013 at 10:46:35AM -0700, H. Peter Anvin wrote:
On 10/02/2013 09:05 AM, Frantisek Hrbata wrote:
+
+int valid_phys_addr_range(phys_addr_t addr, size_t count)
+{
On 10/02/2013 11:48 AM, Frantisek Hrbata wrote:
Ok, I can try to look into this. I just want to point out that some other
archs
like arm are doing it the same way. I simply replaced the generic check
functions
in drivers/char/mem.c with x86 specific ones.
I know. It is a longstanding
On Wed, May 01, 2013 at 11:19:15AM -0700, Dave Hansen wrote:
> On 04/27/2013 08:17 PM, Will Huck wrote:
> >> PTE bits 51 - M are reserved, where M is physical address width
> >> found 2)
> >> Note: step 2) is actually not needed, we can always set just the
> >> 51th bit
> >>
On 04/27/2013 08:17 PM, Will Huck wrote:
>> PTE bits 51 - M are reserved, where M is physical address width
>> found 2)
>> Note: step 2) is actually not needed, we can always set just the
>> 51th bit
>> (0x8)
>
> What's the meaning here? You trigger oops since the address
On 04/27/2013 08:17 PM, Will Huck wrote:
PTE bits 51 - M are reserved, where M is physical address width
found 2)
Note: step 2) is actually not needed, we can always set just the
51th bit
(0x8)
What's the meaning here? You trigger oops since the address is beyond
On Wed, May 01, 2013 at 11:19:15AM -0700, Dave Hansen wrote:
On 04/27/2013 08:17 PM, Will Huck wrote:
PTE bits 51 - M are reserved, where M is physical address width
found 2)
Note: step 2) is actually not needed, we can always set just the
51th bit
(0x8)
Hi Peter,
On 04/28/2013 12:00 PM, H. Peter Anvin wrote:
Not reserved page, reserved bits in the page tables (which includes all bits
beyond the maximum physical address.)
Thanks for your clarify. When these reserved bits are set?
Another question, if configure UMA to fake numa can get
Hi Peter,
On 04/28/2013 12:00 PM, H. Peter Anvin wrote:
Not reserved page, reserved bits in the page tables (which includes all bits
beyond the maximum physical address.)
Thanks for your clarify. When these reserved bits are set?
Another question, if configure UMA to fake numa can get
Not reserved page, reserved bits in the page tables (which includes all bits
beyond the maximum physical address.)
Will Huck wrote:
>On 04/28/2013 03:13 AM, Frantisek Hrbata wrote:
>> On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
>>> On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On 04/28/2013 03:13 AM, Frantisek Hrbata wrote:
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set,
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
> On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
> >On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
> >>Hi Peter,
> >>On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
> >>>When CR4.PAE is set, the 64b PTE's are
On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4
On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is
On 04/28/2013 03:13 AM, Frantisek Hrbata wrote:
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
On 04/26/2013 11:35 PM, Frantisek Hrbata wrote:
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set,
Not reserved page, reserved bits in the page tables (which includes all bits
beyond the maximum physical address.)
Will Huck will.hu...@gmail.com wrote:
On 04/28/2013 03:13 AM, Frantisek Hrbata wrote:
On Sat, Apr 27, 2013 at 03:00:11PM +0800, Will Huck wrote:
On 04/26/2013 11:35 PM, Frantisek
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
> Hi Peter,
> On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
> >When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
> >X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in
> >64b
> >PTE are
On Fri, Apr 26, 2013 at 01:21:28PM +0800, Will Huck wrote:
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in
64b
PTE are reserved
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page
Hi Peter,
On 04/02/2013 08:28 PM, Frantisek Hrbata wrote:
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
> On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
> >
> > Hi, this is exactly what the patch is doing imho. Note that the
> > valid_phys_addr_range(), which is using the high_memory, is the same as the
> > default one in
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
Hi, this is exactly what the patch is doing imho. Note that the
valid_phys_addr_range(), which is using the high_memory, is the same as the
default one in
Hi H.Peter,
On 04/11/2013 10:48 AM, H. Peter Anvin wrote:
On 04/10/2013 07:40 PM, Simon Jeons wrote:
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because
On 04/10/2013 07:40 PM, Simon Jeons wrote:
> Hi H.Peter,
> On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
>> On 04/03/2013 06:11 PM, Simon Jeons wrote:
>>> Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
>>>
>> Because x86_phys_bits is what controls how much address space the
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine
On 04/10/2013 07:40 PM, Simon Jeons wrote:
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor
Hi H.Peter,
On 04/11/2013 10:48 AM, H. Peter Anvin wrote:
On 04/10/2013 07:40 PM, Simon Jeons wrote:
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because
Hi H.Peter,
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
How to check which address is used by mmio? /proc/iomem, correct?
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
On 04/04/2013 10:14 AM, H. Peter Anvin wrote:
Because git didn't exist before then?
Oh, I see, thanks! :-)
Simon Jeons wrote:
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu should not access
Because git didn't exist before then?
Simon Jeons wrote:
>On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
>> On 04/03/2013 06:17 PM, Simon Jeons wrote:
>>> e820 also contain mmio, correct?
>> No.
>>
>>> So cpu should not access address beyond
>>> e820 map(RAM+MMIO).
>> No.
>>
>> -hpa
>>
>>
>
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
One offline question, why can't check git log before 2005?
--
To unsubscribe from
On 04/03/2013 06:17 PM, Simon Jeons wrote:
>
> e820 also contain mmio, correct?
No.
> So cpu should not access address beyond
> e820 map(RAM+MMIO).
No.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine
On 04/03/2013 06:11 PM, Simon Jeons wrote:
>
> Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
>
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine has, or
specifically, how much RAM the machine had on
Hi H.Peter,
On 04/03/2013 02:48 AM, H. Peter Anvin wrote:
On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..39607c6 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -242,6 +242,10 @@ static
Because git didn't exist before then?
Simon Jeons simon.je...@gmail.com wrote:
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
One
On 04/04/2013 10:14 AM, H. Peter Anvin wrote:
Because git didn't exist before then?
Oh, I see, thanks! :-)
Simon Jeons simon.je...@gmail.com wrote:
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu
Hi H.Peter,
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
How to check which address is used by mmio? /proc/iomem, correct?
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
Hi H.Peter,
On 04/03/2013 02:48 AM, H. Peter Anvin wrote:
On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..39607c6 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -242,6 +242,10 @@ static
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine has, or
specifically, how much RAM the machine had on
Hi H.Peter,
On 04/04/2013 09:13 AM, H. Peter Anvin wrote:
On 04/03/2013 06:11 PM, Simon Jeons wrote:
Why we consider boot_cpu_data.x86_phys_bits instead of e820 map here?
Because x86_phys_bits is what controls how much address space the
processor has. e820 tells us how much *RAM* the machine
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 04/04/2013 09:32 AM, H. Peter Anvin wrote:
On 04/03/2013 06:17 PM, Simon Jeons wrote:
e820 also contain mmio, correct?
No.
So cpu should not access address beyond
e820 map(RAM+MMIO).
No.
-hpa
One offline question, why can't check git log before 2005?
--
To unsubscribe from
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
> On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
> >
> > Hi, this is exactly what the patch is doing imho. Note that the
> > valid_phys_addr_range(), which is using the high_memory, is the same as the
> > default one in
On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
>
> Hi, this is exactly what the patch is doing imho. Note that the
> valid_phys_addr_range(), which is using the high_memory, is the same as the
> default one in drivers/char/mem.c(#ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE). I
> just added x86
On Tue, Apr 02, 2013 at 11:48:34AM -0700, H. Peter Anvin wrote:
> On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
> >
> > diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> > index d8e8eef..39607c6 100644
> > --- a/arch/x86/include/asm/io.h
> > +++ b/arch/x86/include/asm/io.h
>
On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
>
> diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
> index d8e8eef..39607c6 100644
> --- a/arch/x86/include/asm/io.h
> +++ b/arch/x86/include/asm/io.h
> @@ -242,6 +242,10 @@ static inline void flush_write_buffers(void)
> #endif
On 04/02, Frantisek Hrbata wrote:
>
> Meaning there is a possibility to use mmap
> on /dev/mem and cause system panic. It's probably not that serious, because
> access to /dev/mem is limited and the system has to have panic_on_oops set,
> but
> still I think we should check this and return error.
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page [1] 4.5 IA-32e Paging: Table 4-19, bits 51-M(MAXPHYADDR)
When CR4.PAE is set, the 64b PTE's are used(ARCH_PHYS_ADDR_T_64BIT is set for
X86_64 || X86_PAE). According to [1] Chapter 4 Paging, some higher bits in 64b
PTE are reserved and have to be set to zero. For example, for IA-32e and 4KB
page [1] 4.5 IA-32e Paging: Table 4-19, bits 51-M(MAXPHYADDR)
On 04/02, Frantisek Hrbata wrote:
Meaning there is a possibility to use mmap
on /dev/mem and cause system panic. It's probably not that serious, because
access to /dev/mem is limited and the system has to have panic_on_oops set,
but
still I think we should check this and return error.
On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..39607c6 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -242,6 +242,10 @@ static inline void flush_write_buffers(void)
#endif
}
On Tue, Apr 02, 2013 at 11:48:34AM -0700, H. Peter Anvin wrote:
On 04/02/2013 05:28 AM, Frantisek Hrbata wrote:
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d8e8eef..39607c6 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -242,6
On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
Hi, this is exactly what the patch is doing imho. Note that the
valid_phys_addr_range(), which is using the high_memory, is the same as the
default one in drivers/char/mem.c(#ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE). I
just added x86 specific
On Tue, Apr 02, 2013 at 01:29:12PM -0700, H. Peter Anvin wrote:
On 04/02/2013 12:10 PM, Frantisek Hrbata wrote:
Hi, this is exactly what the patch is doing imho. Note that the
valid_phys_addr_range(), which is using the high_memory, is the same as the
default one in
66 matches
Mail list logo
