Subject: Re: [RFC PATCH] kvm: Make KVM DF intercept configurable
To: Borislav Petkov <bp@alien8.de>, Paolo Bonzini <pbonzini@redhat.com>
References: <20160301192822.GD22677@pd.tnic> <56D6059D.5050606@redhat.com>
 <20160301224132.GE22677@pd.tnic>
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>
From: Jan Kiszka <jan.kiszka@siemens.com>
Message-ID: <56D68C21.7080602@siemens.com>
Date: Wed, 2 Mar 2016 07:45:53 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12)
 Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
In-Reply-To: <20160301224132.GE22677@pd.tnic>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1438
Lines: 39

On 2016-03-01 23:41, Borislav Petkov wrote:
> 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.

To make this a serious debug feature, we should consider trapping all
exceptions on request (and reinjecting the unhandled ones). Not sure
right now, though, if that comes with more complications than the simple
#DF case.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux