On Mon, 12 Nov 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/6/18 2:20 PM, Julien Grall wrote:
> > On 05/11/2018 17:56, Stefano Stabellini wrote:
> > > On Mon, 5 Nov 2018, Julien Grall wrote:
> > > > On 02/11/2018 23:27, Stefano Stabellini wrote:
> > > > > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > > >
> > > > > > + /*
> > > > > > + * Now that the work on the entry is done, set the valid bit to
> > > > > > prevent
> > > > > > + * another fault on that entry.
> > > > > > + */
> > > > > > + resolved = true;
> > > > > > + entry.p2m.valid = 1;
> > > > > > +
> > > > > > + p2m_write_pte(table + offsets[level], entry, p2m->clean_pte);
> > > > > > +
> > > > > > + /*
> > > > > > + * No need to flush the TLBs as the modified entry had the
> > > > > > valid bit
> > > > > > + * unset.
> > > > > > + */
> > > > > > +
> > > > > > +out_unmap:
> > > > > > + unmap_domain_page(table);
> > > > > > +
> > > > > > +out:
> > > > > > + p2m_write_unlock(p2m);
> > > > > > +
> > > > > > + return resolved;
> > > > > > +}
> > > > > > +
> > > > > > static inline int p2m_insert_mapping(struct domain *d,
> > > > > > gfn_t start_gfn,
> > > > > > unsigned long nr,
> > >
> > >
> > > We probably want to update the comment on top of the call to
> > > p2m_resolve_translation_fault:
> >
> > Whoops. I will fix it.
>
> Looking at this again. I think the comment on top of the call to
> p2m_resolve_translation_fault still makes sense. Feel free to suggest an
> update of the comment if you think it is not enough.
/*
* The PT walk may have failed because someone was playing with
* the Stage-2 page table or because the valid bit was left
* unset to track memory accesses. In these cases, we want to
* return to the guest.
*/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel