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

Re: [Xen-devel] [RFC] x86: more debugging adjustments


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 22 Nov 2007 16:14:01 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 22 Nov 2007 08:14:54 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcgtIrF98EtsDJkVEdybPwAX8io7RQ==
  • Thread-topic: [Xen-devel] [RFC] x86: more debugging adjustments

On 22/11/07 15:47, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> * Why do some instruction emulations pass NULL to update_guest_eip() and
>> hence bypass #DB injection? That seems bogus.
> 
> That's intentional (to a certain degree): Especially for the HLT case I wasn't
> really certain injecting an exception here would have the intended effect.
> I'm pretty sure you'd have to suppress the normal HLT handling in that case,
> and it seemed safer for a first cut to not inject an exception at all here
> (thus
> simply retaining current behavior for this special case).
> For SVM's VMEXIT_EXCEPTION_BP case it seems certainly wrong to inject
> one.

Ah, you could be right. I don't have that much experience with EFLAGS.TF,
but from the reference manuals it looks rather as if, on return from an
exception or interrupt, when EFLAGS.TF is re-set by IRET, you actually do
not #DB with EIP pointing at the instruction you IRET to? And this is
because single-step #DB is a trap? Also I suppose that a software exception
or interrupt causes single-step #DB to be skipped when you actually execute
INT n, INT3, INTO or whatever. So you effectively never see single-step #DB
with EIP pointing at the instruction following one of those INT
instructions?

I suppose I could validate this for myself. :-)

Anyway, apart from that the patches are fine. Re-submit with Signed-off-by
lines and I'll drop them in.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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