Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
>> I suspect what we want to do is come up with a function to call
>> to test to see if a page should be read-only and map such pages
>> _PAGE_KERNEL_RO, or _PAGE_KERNEL_RO_EXEC if it's code.
>>
>
> Hm, I think that's a hard function to write in g
Eric W. Biederman wrote:
I suspect what we want to do is come up with a function to call
to test to see if a page should be read-only and map such pages
_PAGE_KERNEL_RO, or _PAGE_KERNEL_RO_EXEC if it's code.
Speaking of things what are paravirt_alloc_pd and parafirt_alloc_pd
supposed to do?
Eric W. Biederman wrote:
>> The issue is not a matter of avoiding duplicate work, but making sure
>> all the pagetables are consistent from Xen's perspective.
>>
>> Specifically, you may not ever, at any time, create a writable mapping
>> of a page which is currently part of an active pagetable. T
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> No. Please just remove the conditionals on the leaf pages.
>>
>
> So, to be specific, you mean make updating the pte_t entries (and pmd_t
> entries which refer to hugepages) entries unconditional?
I mean make updati
Eric W. Biederman wrote:
> No. Please just remove the conditionals on the leaf pages.
>
So, to be specific, you mean make updating the pte_t entries (and pmd_t
entries which refer to hugepages) entries unconditional?
> We know exactly what we require them to be, there is minimal
> cost and no
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Nope. It's not overwriting anything.
>
> This should fix it.
>
> Subject: x86: fix PSE pagetable construction
>
> When constructing the initial pagetable in pagetable_init, make sure
> that non-PSE pmds are updated to P
Eric W. Biederman wrote:
> Nope. It's not overwriting anything.
This should fix it.
Subject: x86: fix PSE pagetable construction
When constructing the initial pagetable in pagetable_init, make sure
that non-PSE pmds are updated to PSE ones.
This moves the definition of pmd_huge() out of the hu
Eric W. Biederman wrote:
>> Hm, but it should be overwriting small mappings with large ones. Maybe
>> I overlooked that.
>>
>
> Nope. It's not overwriting anything.
It will work if we just overwrite the pmd's with large pages in the PSE
case, since Xen doesn't support PSE. Or we could only
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> I might have introduced it as part of the paravirt_ops patches. When
> setting up pagetables under Xen, we need to make sure we preserve the
> initial mappings Xen put in place (it starts the VM with paging enabled,
> and a sane initial pagetable)
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>> This patch only affects the initial page tables, which should have been
>>> thrown out *way* long ago at this point.
>>
>> Yes. I noticed this was happening a few days ago.
>> I must not have mentioned it loudly enough.
Eric W. Biederman wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
>
>> Andrew Morton wrote:
>>
>>
>>> This patch causes oopses after a minute or so running LTP's
>>>
>>> ./testcases/bin/growfiles -W gf16 -b -e 1 -i 0 -L 120 -u -g 4090 -T 100 -t
>>>
>> 408990 -l -C 10 -c 1000
Eric W. Biederman wrote:
>> This patch only affects the initial page tables, which should have been
>> thrown out *way* long ago at this point.
>
> Yes. I noticed this was happening a few days ago.
> I must not have mentioned it loudly enough.
You mentioned the continued use of init_mm. This is
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Andrew Morton wrote:
>
>>
>> This patch causes oopses after a minute or so running LTP's
>>
>> ./testcases/bin/growfiles -W gf16 -b -e 1 -i 0 -L 120 -u -g 4090 -T 100 -t
> 408990 -l -C 10 -c 1000 -S 10 -f Lgf02_
>>
>> on everyone's favoutite Vaio,
Andrew Morton wrote:
>
> This patch causes oopses after a minute or so running LTP's
>
> ./testcases/bin/growfiles -W gf16 -b -e 1 -i 0 -L 120 -u -g 4090 -T 100 -t
> 408990 -l -C 10 -c 1000 -S 10 -f Lgf02_
>
> on everyone's favoutite Vaio, configured with
> http://userweb.kernel.org/~akpm/conf
On Fri, 13 Apr 2007 14:49:57 -0700 "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> We just discovered that the accounting for initial memory usage
> (head.S: INIT_MAP_BEYOND_END) has been way, way off for a very long
> time. This patch makes the initial page table not round up to the
> nearest 4M b
H. Peter Anvin wrote:
Zachary Amsden wrote:
H. Peter Anvin wrote:
+/*
+ * End condition: we must map up to and including
+ * INIT_MAP_BEYOND_END bytes beyond the end of our
+ * own page tables; 0x1000 is the size of the page
+ * table were about to write, and +0x007 is the
+
Zachary Amsden wrote:
> H. Peter Anvin wrote:
>> +/*
>> + * End condition: we must map up to and including
>> + * INIT_MAP_BEYOND_END bytes beyond the end of our
>> + * own page tables; 0x1000 is the size of the page
>> + * table were about to write, and +0x007 is the
>> + *
Zachary Amsden wrote:
H. Peter Anvin wrote:
+/*
+ * End condition: we must map up to and including
+ * INIT_MAP_BEYOND_END bytes beyond the end of our
+ * own page tables; 0x1000 is the size of the page
+ * table were about to write, and +0x007 is the
+ * attribute bits.
H. Peter Anvin wrote:
+ /*
+* End condition: we must map up to and including
+* INIT_MAP_BEYOND_END bytes beyond the end of our
+* own page tables; 0x1000 is the size of the page
+* table were about to write, and +0x007 is the
+* attribute bits.
+
We just discovered that the accounting for initial memory usage
(head.S: INIT_MAP_BEYOND_END) has been way, way off for a very long
time. This patch makes the initial page table not round up to the
nearest 4M boundary, but instead stop dead (and zero the rest of the
final page table) as soon as it
20 matches
Mail list logo
