On Thu, Dec 13, 2018 at 6:26 AM Jan Beulich <jbeul...@suse.com> wrote:
>
> >>> On 01.12.18 at 02:33, <christopher.w.cl...@gmail.com> wrote:
> > so that the guest may re-register the rings on resume with current mappings.
>
> Is this something guests really need help with, rather than managing
> it on their own? What does "current mappings" here mean, i.e. why
> do rings need re-registration in the first place?
My understanding is that the gfn->mfn mapping is not necessarily
stable across entry and exit to host S4, suspend to disk, so the
rings need to be torn down before suspend to stop further writes
into those pages after resume.
When the guest gets the notification after resume, it can
re-register the rings with its list of gfns, which can then
be re-translated into the (possibly) new mfns needed for the ring.

> > +void
> > +argo_resume(struct domain *d)
> > +{
> > +    bool send_wakeup;
> > +
> > +    if ( !d )
> > +        return;
> > +
> > +    if ( !get_domain(d) )
> > +        return;
> > +
> > +    read_lock(&argo_lock);
> > +
> > +    read_lock(&d->argo->lock);
> > +    send_wakeup = ( d->argo->ring_count > 0 );
> > +    read_unlock(&d->argo->lock);
> > +
> > +    if ( send_wakeup )
> > +        argo_signal_domain(d);
> > +
> > +    read_unlock(&argo_lock);
> > +
> > +    put_domain(d);
> > +}
>
> domain_resume() also gets called from domain_soft_reset(). Do
> you really want such handling in that case as well, when after a
> soft-reset the domain is supposed to be "blank"?

Thanks for the pointer to soft reset: I've added implementation
for this to the next version of the patch series, and it'll be fine
with resume then.

Christopher

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

Reply via email to