This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: Xen MMU's requirement to pin pages RO and initial_memory

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: [Xen-devel] Re: Xen MMU's requirement to pin pages RO and initial_memory_mapping.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Mon, 16 May 2011 11:23:14 +0100
Cc: "jeremy@xxxxxxxx" <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "hpa@xxxxxxxxxxxxxxx" <hpa@xxxxxxxxxxxxxxx>, "yinghai@xxxxxxxxxx" <yinghai@xxxxxxxxxx>
Delivery-date: Mon, 16 May 2011 03:22:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110513153010.GB16519@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110513153010.GB16519@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 13 May 2011, Konrad Rzeszutek Wilk wrote:
> aka, remove the hack added by git commit 
> 609cfda586c7fe3e5d1a02c51edb587506294167
> (Merge branch 'stable/bug-fixes-for-rc5' of git://git.kernel.org/../xen)
> One idea that is on the table was proposed by Yinghai:
> "Xen should set RAM for page-table to RO after init_memory mapping."
> In other words, don't do the magic 'mask_rw_pte' when set_pte is called.
> (and don't do the calls to make_lowmem_page_readonly when allocating
> the PTE table, nor PMD, nor PUD) - I think?
> But instead do:
>  a). when we load the cr3? We could go through the whole pagetable and
>      set the RO as we need?
>  b). when we are finished with the creation of a page table? So similary 
>      to the point above - don't set the RO on the pages until we have 
> completed
>      the full creation of the page.
>  c). when post_allocator_start is called?

I think c) is too late because there might be allocations or at least
memblock allocations after init_memory_mapping and before

>  d). other ideas?
> But I vaguelly recall that we are using the page table as we are adding in the
> entries. And that we are pinning them as well. Perhaps the trigger to scan the
> pagetable and set them to RO should be done .. at what point? When the PUD/PMD
> allocations are done? And when PUD/PMD are set?

Setting the pagetable pages RO after init_memory_mapping is difficult
because pagetable pages have to be set RO before becoming pagetable
They become pagetable pages when:

- they are explicitly pinned by pin_pagetable_pfn

- they are hooked into the current pagetable

Like you wrote, considering that the x86_64 version of
kernel_physical_mapping_init hooks the pagetable pages into the
currently used pagetable, it wouldn't be possible to mark the pagetable
pages RO after init_memory_mapping.

Xen-devel mailing list