From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ed White <edmund.h.white@intel.com>
Subject: Re: [PATCH 08/11] x86/altp2m: add remaining support
	routines.
Date: Thu, 15 Jan 2015 13:00:48 -0800
Message-ID: <54B82A80.2000709@intel.com>
References: <1420838801-11704-1-git-send-email-edmund.h.white@intel.com>
	<1420838801-11704-9-git-send-email-edmund.h.white@intel.com>
	<20150115173357.GK57240@deinos.phlegethon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20150115173357.GK57240@deinos.phlegethon.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tim Deegan <tim@xen.org>
Cc: keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com, jbeulich@suse.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 01/15/2015 09:33 AM, Tim Deegan wrote:
> Hi,
> 
> Sorry for the fractured replies - my notes are confused about which
> functions were defined where.
> 
> At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
>> +bool_t p2m_change_altp2m_pfn(struct domain *d, uint16_t idx,
>> +                             unsigned long old_pfn, unsigned long new_pfn)
>> +{
> [...]
>> +    mfn = ap2m->get_entry(ap2m, new_pfn, &t, &a, 0, NULL);
>> +
>> +    if ( !mfn_valid(mfn) )
>> +        mfn = hp2m->get_entry(hp2m, new_pfn, &t, &a, 0, NULL);
>> +
>> +    if ( !mfn_valid(mfn) || !(t == p2m_ram_rw || t == p2m_ram_rw) )
>> +        goto out;
>> +
>> +    /* Use special ram type to enable #VE if setting for current domain */
>> +    if ( current->domain == d )
>> +        t = p2m_ram_rw_ve;
>> +
>> +    if ( !ap2m->set_entry(ap2m, old_pfn, mfn, PAGE_ORDER_4K, t, a) )
>> +        rc = 1;
> 
> I'm afraid this is Terribly Unsafe[tm].  Following on from my point on
> the log-dirty patch, if the original gfn gets removed from the guest,
> for any reason, we need a way to find and remove this mapping too.
> 
> That will be non-trivial, since you can't do it by exhaustive search.
> Maybe some sort of reverse mapping?

How often is it likely that a page will be removed? If it's
infrequent, maybe an exhaustive search will suffice. I don't
expect there to be anywhere near 10 alternates in use in most
cases, and they are sparsely populated.

Ed