On Tue, Mar 01, 2016 at 10:11:57PM +0100, Paolo Bonzini wrote:
> I just use QEMU's binary translation mode to debug this kind of code (-d
> in_asm is useful and relatively compact (because it only shows loops
> once),
Ha, I had forgotten about "in_asm"! Thanks for reminding me, that's a
really cool feature I'm going to use. With it I see:
----------------
IN:
0x0000000001000000: mov 0xffffffff81cba1f8,%rsp
0x0000000001000008: callq 0x10001a9
----------------
Now, it is obvious that 0xffffffff81cba1f8 is not mapped yet and we're
running from physical addresses. The DF tracepoint shows, in addition,
the previous exception vector causing the DF and I think that's useful.
As an additional debugging aid. Oh, and that doesn't need ept=0 and runs
at full speed.
> or alternatively ept=0. But perhaps... why not. :) It's not like it
> adds overhead.
Yeah, it is off by default and doesn't hurt anyone. And the diff size
is ok, IMHO. Lemme code the Intel side too and see how the whole thing
turns out.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
