On Wed, 22 Aug 2012, Attilio Rao wrote:
> - Allow xen_mapping_pagetable_reserve() to handle a start different from
> pgt_buf_start, but still bigger than it.
What's the purpose of this and how is this going to be used and how is
it useful at all?
> - Add checks to xen_mapping_pagetable_reserve() and native_pagetable_reserve()
> for verifying start and end are contained in the range
> [pgt_buf_start, pgt_buf_top].
> - In xen_mapping_pagetable_reserve(), change printk into pr_debug.
> - In xen_mapping_pagetable_reserve(), print out diagnostic only if there is
> an actual need to do that (or, in other words, if there are actually some
> pages going to switch from RO to RW).
Please stop telling what the patch is doing. I can read that from the
patch itself. Please tell _WHY_ it is doing it.
> Signed-off-by: Attilio Rao <attilio....@citrix.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> Acked-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
> ---
> arch/x86/mm/init.c | 4 ++++
> arch/x86/xen/mmu.c | 22 ++++++++++++++++++++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index e0e6990..f4b750d 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -92,6 +92,10 @@ static void __init find_early_table_space(struct map_range
> *mr, unsigned long en
>
> void __init native_pagetable_reserve(u64 start, u64 end)
> {
> + if (start < PFN_PHYS(pgt_buf_start) || end > PFN_PHYS(pgt_buf_top))
This check is useless. We initialize pgt_buf_start,end,top to:
pgt_buf_start = base >> PAGE_SHIFT;
pgt_buf_end = pgt_buf_start;
pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
in find_early_table_space(). pgt_buf_end gets modified only in
alloc_low_page()
unsigned long pfn = pgt_buf_end++;
And both implementations (32/64bit) have the following check:
if (pfn >= pgt_buf_top)
panic("alloc_low_page: ran out of memory");
So we panic way before we reach this check. Extra panic safety or what
are you trying to do here?
I also have a hard time to understand the first part of the check.
There is only one callsite which feeds PFN_PHYS(pgt_buf_start) as
first argument. And as long as you don't explain WHY it would be
useful and a good idea to change that, this is pointless.
> + panic("Invalid address range: [%#llx-%#llx] should be a subset
> of [%#llx-%#llx]\n",
> + start, end, (u64)PFN_PHYS(pgt_buf_start),
> + (u64)PFN_PHYS(pgt_buf_top));
> memblock_reserve(start, end - start);
> }
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b65a761..dfae43a 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1180,12 +1180,30 @@ static void __init xen_pagetable_setup_start(pgd_t
> *base)
>
> static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
> {
> + u64 begin;
> +
> + begin = PFN_PHYS(pgt_buf_start);
> +
> + if (start < begin || end > PFN_PHYS(pgt_buf_top))
> + panic("Invalid address range: [%#llx-%#llx] should be a subset
> of [%#llx-%#llx]\n",
> + start, end, begin, (u64)PFN_PHYS(pgt_buf_top));
> +
> + /* set RW the initial range */
> + if (start != begin)
And how does this happen? Again, that function is called from one
place and start _IS_ equal to PFN_PHYS(pgt_buf_start).
> + pr_debug("xen: setting RW the range [%#llx-%#llx]\n",
> + begin, start);
> + while (begin < start) {
> + make_lowmem_page_readwrite(__va(begin));
> + begin += PAGE_SIZE;
> + }
> +
> /* reserve the range used */
> native_pagetable_reserve(start, end);
>
> /* set as RW the rest */
> - printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
> - PFN_PHYS(pgt_buf_top));
> + if (end != PFN_PHYS(pgt_buf_top))
So this check is the only useful addition of this patch so far, unless
you come up with some useful explanations.
> + pr_debug("xen: setting RW the range [%#llx-%#llx]\n",
> + end, (u64)PFN_PHYS(pgt_buf_top));
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
