Re: [Xen-devel] [XEN PATCH v1 1/1] x86/vm_event: add fast single step

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Dec 17, 2019 at 8:08 AM Tamas K Lengyel <tamas@xxxxxxxxxxxxx> wrote:
>
> On Tue, Dec 17, 2019 at 7:48 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
> wrote:
> >
> > On 17/12/2019 14:40, Sergey Kovalev wrote:
> > > On break point event eight context switches occures.
> > >
> > > With fast single step it is possible to shorten path for two context
> > > switches
> > > and gain 35% spead-up.
> > >
> > > Was tested on Debian branch of Xen 4.12. See at:
> > > https://github.com/skvl/xen/tree/debian/knorrie/4.12/fast-singlestep
> > >
> > > Rebased on master:
> > > https://github.com/skvl/xen/tree/fast-singlestep
> > >
> > > Signed-off-by: Sergey Kovalev <valor@xxxxxxx>
> >
> > 35% looks like a good number, but what is "fast single step"?  All this
> > appears to be is plumbing for to cause an altp2m switch on single step.
>
> Yes, a better explanation would be much needed here and I'm not 100%
> sure it correctly implements what I think it tries to.
>
> This is my interpretation of what the idea is: when using DRAKVUF (or
> another system using altp2m with shadow pages similar to what I
> describe in 
> https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
> after a breakpoint is hit the system switches to the default
> unrestricted altp2m view with singlestep enabled. When the singlestep
> traps to Xen another vm_event is sent to the monitor agent, which then
> normally disables singlestepping and switches the altp2m view back to
> the restricted view. This patch looks like its short-circuiting that
> last part so that it doesn't need to send the vm_event out for the
> singlestep event and should switch back to the restricted view in Xen
> automatically. It's a nice optimization. But what seems to be missing
> is the altp2m switch itself.

Never mind, p2m_altp2m_check does the altp2m switch as well, so this
patch implements what I described above. Please update the patch
message to be more descriptive (you can copy my description from
above).

Thanks!
Tamas

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