>>> On 15.01.15 at 22:00, <edmund.h.wh...@intel.com> wrote:
> 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.
A fundamental thing you need to keep in mind when considering
exhaustive searches is that these need to be preemptible, no
matter how infrequent they are. Which may be difficult to
arrange for, based on experience with code where we needed
to add such preemption later on (as security fixes).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
