Re: [Xen-devel] [PATCH 08/11] x86/altp2m: add remaining support routines.

[Ed White <edmund.h.white@xxxxxxxxx>]

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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel