[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] AMD support of hvm_vcpu.single_step



On 06/11/2014 07:04 PM, Mukesh Rathor wrote:
On Wed, 11 Jun 2014 18:55:53 -0400
Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:

On 06/11/2014 06:32 PM, Mukesh Rathor wrote:
On Wed, 11 Jun 2014 11:56:15 -0400
Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:

On 06/10/2014 05:49 PM, Mukesh Rathor wrote:
Hi AMD folks,

I am unable to see support of single step on amd platform. On
intel, hvm_vcpu.single_step will cause MTF to be set in
vmx_intr_assist:

       /* Block event injection when single step with MTF. */
       if ( unlikely(v->arch.hvm_vcpu.single_step) )
       {
           v->arch.hvm_vmx.exec_control |=
CPU_BASED_MONITOR_TRAP_FLAG; vmx_update_cpu_exec_control(v);
           return;
       }

I don't see equivalent on amd?
I think HW performs TF bit manipulations that your patch is
suggesting (per 13.1.4 of APMv2)
It only clears it, not set it. Patch on the way.

Does it need to be set? My understanding is that it is supposed to be
clear in the handler (in the guest) but set on the exception's stack
so when the guest does the IRET it loads TF=1.
If a debugger wants to single step, it needs to set the TF. So this
is for the debugger path. The hardware clears it upon execution of next
instruction, and generates #DB.

The patch seems to be setting TF when returning from #DB intercept, right? Won't this result in another #DB on the first instruction of guest's #DB handler?

-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.