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


Re: [Xen-devel] [PATCH] linux/x86-64: allow kernel init memory to be fre

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>,"Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] linux/x86-64: allow kernel init memory to be freed
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 02 Mar 2007 16:01:36 +0000
Delivery-date: Fri, 02 Mar 2007 08:00:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C20DF1FC.A826%keir@xxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45E812E4.76E4.0078.0@xxxxxxxxxx> <C20DF1FC.A826%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 02.03.07 16:23 >>>
>On 2/3/07 11:04, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> +  if (addr >= __START_KERNEL_map) {
>> +   /* make_readonly() reports all kernel addresses. */
>> +   __make_page_writable(__va(__pa(addr)));
>> +   __make_page_readonly((void *)addr);
>> +  }
>I'm confused by this:
> 1. Why does the write-protection need to be changed unconditionally, or
>even at all? Is there anything write-protected in the init sections?

The mappings in the direct map area must be writeable and, as the comment
says, make_readonly() forces all kernel space mappings to be set up as
read-only during boot. Thus this does *not* depend on
XENFEAT_writable_page_tables, unless make_readonly() is changed.

> 2. Is it safe to keep init mappings above START_KERNEL_map at all, even
>read-only? I'd have thought we'd be in trouble if the balloon driver manages
>to allocate those pages and tries to free them to Xen. Perhaps they should
>be blown away entirely?

Yes, ultimately I wanted them to go away entirely, likewise in native. That is
why I wanted to push this change through mainline rather than directly into
Xen (it also is somewhat more involved as I [mis-]use change_page_attr_addr()
here instead of creating a new function to do this zapping, and as I also at
once extend the range mark_rodata_ro() handles).
But indeed, I didn't consider the balloon driver here, which would - as I
understand it now - erroneously think it freed such pages when Xen really
didn't due to a remaining reference.
So - would you be okay with taking the full-blown patch (probably not, as it
touches another file not currently in the sparse tree), or should I create a
__make_page_inaccessible() function along the lines of


Xen-devel mailing list