From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2] KVM: VMX: Conditionally reload debug register 6 Date: Tue, 01 Sep 2009 19:21:24 +0300 Message-ID: <4A9D4A04.8080009@redhat.com> References: <1251810385-21050-1-git-send-email-avi@redhat.com> <4A9D1E57.4010501@siemens.com> <4A9D2318.9000000@redhat.com> <4A9D25FD.9070001@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38443 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754948AbZIAQV0 (ORCPT ); Tue, 1 Sep 2009 12:21:26 -0400 In-Reply-To: <4A9D25FD.9070001@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/01/2009 04:47 PM, Jan Kiszka wrote: >> btw, something else I've considered was not to do any emulation for 'mov >> dr' but instead load the debug registers and disable the intercept. So >> far the only issue I've seen is that we lose support for real mode guest >> self-debug on intel (pre-unrestricted guest). What do you think of this? >> > I think you can't have both: optimized dr save/restore on vmentry/exit > and optimized dr access. If you drop on-demand dr register > readout/update, you need to deal with this on every vmentry/exit. My > feeling is that this would be awfully slower, even slower than what we > currently have without your patches. > I'll clarify: In the normal case, we'll have #DB and MOV DR intercepted. On #DB, update vcpu->dr6. On MOV DR, disable MOV DR interception, enable dr swap, and let the guest execute; on the next exit, reenable MOV DR interception and disable dr swap. It's similar to the fpu code where we don't emulate fpu instructions. It doesn't really buy us a lot. -- error compiling committee.c: too many arguments to function