| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC] x86: more debugging adjustments
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 22.11.07 15:50 >>>
>Inject-sstep: Looks fine in principle. A few specific questions:
> * Why is all the RFLAGS.RF logic removed from platform.c?
As it seems to me it was misplaced there (yes, I added it, but I probably
didn't understand the execution flow properly back then). The instruction
completes in hvm_io_assist(), there's no register state writeback elsewhere
that I could see, and hence the updating of EFLAGS.RF also belongs just
there.
> * Why is DR6 adjustment done in svm_hvm_inject_exception() rather than
>svm_inject_exception() (to match vmx_inject_exception())?
Because
a) svm_hvm_inject_exception() is the counterpart of vmx_inject_exception(),
svm_inject_exception() is an internal helper.
> * 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.
>Io-brkp: This one needs more explanation about exactly what things are being
>improved. There's more going on here than your brief explanation below. My
Oh, I see that I didn't describe the original purpose of emulating the #DB
on I/O port accesses - I must have thought that this is implied by the name.
This is being done by not committing the respective enable bits to %dr7,
but rather tracking them in the DR5 shadow.
Beyond that, the only things I didn't describe are mere cleanup items, like
replacing numeric literals with manifest constants.
>only comment at this point is that I don't see that supporting CR4.DE==0 is
You probably mean CR4.DE==1? If you doubt that, why did you apply the
recent change to allow the guest to drive the bit?
>very useful. I don't subscribe to the view that we should support every
>little detail of x86 architecture just because it's there, especially for PV
>guests.
I think that a kernel debugger in a guest should certainly have the capability
of doing this, but I understand your reservation to a certain degree.
>All other patches are applied and I queued up a couple for 3.1.3 also.
Thanks. Btw., the 'official' tree appears to be stuck again...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home