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

Re: [Xen-devel] [V0 PATCH] SVM: set/unset TF flag for single_step



>>> On 02.07.14 at 23:52, <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 02 Jul 2014 09:38:40 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 02.07.14 at 05:36, <boris.ostrovsky@xxxxxxxxxx> wrote:
>> >> --- a/xen/arch/x86/hvm/svm/svm.c
>> >> +++ b/xen/arch/x86/hvm/svm/svm.c
>> >> @@ -2350,6 +2350,8 @@ void svm_vmexit_handler(struct cpu_user_regs
>> >> *regs)
>> >>      case VMEXIT_EXCEPTION_DB:
>> >>          if ( !v->domain->debugger_attached )
>> >>              goto exit_and_crash;
>> >> +        else
>> >> +            regs->eflags &= ~X86_EFLAGS_TF;
>> >>          domain_pause_for_debugger();
>> >>          break;
>> > 
>> > 
>> > I poked around debugger code and it looks to me that 
>> > tools/debugger/gdbsx/xg:_change_TF() manages this flag.
> 
> _change_TF() only manages TF if XEN_DOMCTL_debug_op fails. Moreover, TF
> handling is intended for PV. For HVM, xen provides 
> XEN_DOMCTL_debug_op which sets v->arch.hvm_vcpu.single_step.

Maybe this is how things are expected to work right now (I admit
to know very little about the specific debugger interface in Xen),
but conceptually this is wrong (and I say this having written a
number of kernel debuggers outside of Xen): Since the next thing
done in the code path above is pausing the domain for debugging,
and since the debugger ought to have control over the entire
register state, it clearly has the power of setting TF to its liking,
and hence no action on it should be needed here.

Jan


_______________________________________________
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®.