Re: [Xen-devel] Weird altp2m behaviour when switching early to a new view

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 04/17/2018 11:50 AM, Razvan Cojocaru wrote:
>  void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
>  {
>      struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
> +    struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>      struct ept_data *ept;
>  
> +    p2m->max_mapped_pfn = hostp2m->max_mapped_pfn;
> +    p2m->default_access = hostp2m->default_access;
> +    p2m->domain = hostp2m->domain;
> +    p2m->logdirty_ranges = hostp2m->logdirty_ranges;
> +    p2m->global_logdirty = hostp2m->global_logdirty;

This would certainly be one approach.  But then we'd need to keep a lot
more of these things in sync -- for instance, we'd have to have similar
code to enable and disable global_logdirty on all active altp2m entries.

I also don't think the max_mapped_pfn should be copied here; the fact
that updates got filtered out before was a red herring I think.

Another approach would be to maintain the logdirty_ranges and
global_logdirty only for the host p2m, but to misconfigure entries for
all the p2ms; and then on a misconfiguration, handle the
misconfiguration for the hostp2m and then do a lazy propagate for the
altp2m.  On the whole that's probably more error-prone than just doing a
for() loop, though, and not that much faster. :-)

The other thing that seems to be missing from synchronization is that in
p2m-ept.c:ept_enable_pml() sets the p2m->ept.ad bit (which ends up being
part of the eptp).  The code seems to indicate that this is required for
PML (hardware-assisted logdirty), but I don't see anywhere this is set
or copied from the host p2m.

It might be nice to have a more structured way of keeping all these
changes in sync, rather than relying on this open-coding everywhere.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel