On Thu, Jun 25, 2015 at 4:27 PM, Ed White <edmund.h.wh...@intel.com> wrote:
> On 06/25/2015 10:42 AM, Lengyel, Tamas wrote:
> > On Thu, Jun 25, 2015 at 12:31 PM, Ed White <edmund.h.wh...@intel.com>
> wrote:
> >
> >> On 06/24/2015 07:44 PM, Lengyel, Tamas wrote:
> >>>> + if ( altp2m_active )
> >>>> + {
> >>>> + if ( altp2mhvm_hap_nested_page_fault(v, gpa, gla, npfec,
> &p2m)
> >> ==
> >>>> 1 )
> >>>> + {
> >>>> + /* entry was lazily copied from host -- retry */
> >>>>
> >>>
> >>> So I'm not fully following this logic here. I can see that the altp2m
> >> entry
> >>> got copied from the host. Why is there a need for the retry, why not
> just
> >>> continue?
> >>
> >> At this point the EPT's that the hardware is using have been made valid
> >> by software, but the hardware has already failed the access so you have
> >> to restart the operation. This isn't in any way specific to altp2m,
> >> it's how page fault logic works generally.
> >>
> >> Ed
> >>
> >
> > Oh I see, you are working with the assumption that the fault was
> triggered
> > by the entry not being present in the altp2m EPT, thus it's enough to
> copy
> > it to resolve the fault. However, if the hostp2m permissions are
> > restricted, there will be a follow-up fault again. Would it maybe make
> > sense to check for that condition and save having to hit two faults?
>
> It's not an assumption, it's a fact because the altp2m nested page fault
> handler returns 1 IFF it has copied from the host p2m.
>
> Once again this is standard page fault handling. Preemptively checking
> for a condition that would cause another fault shortens the path for
> cases that would re-fault, but lengthens it for all the cases that would
> not. In a typical scenario (which your current experiments are not) you
> expect most cases not to re-fault. The cases that do re-fault are much
> more expensive anyway.
>
> There are other reasons not to preemptively check, but that's the most
> straightforward one.
>
> Ed
>
OK, thanks, makes sense.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
