[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

Cheers,

Tim.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.