Date: Tue, 1 Mar 2016 23:41:32 +0100
From: Borislav Petkov <bp@alien8.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: =?utf-8?B?SsO2cmcgUsO2ZGVs?= <joro@8bytes.org>,
        Andy Lutomirski <luto@amacapital.net>, x86-ml <x86@kernel.org>,
        kvm ML <kvm@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] kvm: Make KVM DF intercept configurable
Message-ID: <20160301224132.GE22677@pd.tnic>
References: <20160301192822.GD22677@pd.tnic>
 <56D6059D.5050606@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <56D6059D.5050606@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1104
Lines: 35

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.