From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Debug-Registers in HVM domain destroyed Date: Fri, 14 Feb 2014 13:02:12 +0000 Message-ID: <52FE21E4020000780011C6F5@nat28.tlf.novell.com> References: <52FDE2ED.4030008@ts.fujitsu.com> <52FE00C8020000780011C649@nat28.tlf.novell.com> <52FE09A2.4000909@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WEIPH-0003JU-H5 for xen-devel@lists.xenproject.org; Fri, 14 Feb 2014 13:02:15 +0000 In-Reply-To: <52FE09A2.4000909@ts.fujitsu.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 14.02.14 at 13:18, Juergen Gross wrote: > On 14.02.2014 11:40, Jan Beulich wrote: >>>>> On 14.02.14 at 10:33, Juergen Gross wrote: >>> Debug registers are restored on vcpu switch only if db7 has any debug events >>> activated. This leads to problems in the following cases: >>> >>> - db0-3 are changed by the guest before events are set "active" in db7. In > case >>> of a vcpu switch between setting db0-3 and db7, db0-3 are lost. BTW: > setting >>> db7 before db0-3 is no option, as this could trigger debug interrupts due > to >>> stale db0-3 contents. >>> >>> - single stepping is used and vcpu switch occurs between the single step trap >>> and reading of db6 in the guest. db6 contents (single step indicator) > are >>> lost in this case. >> >> Not exactly, at least not looking at how things are supposed to work: >> __restore_debug_registers() gets called when >> - context switching in (vmx_restore_dr()) >> - injecting TRAP_debug > > Is this the case when the guest itself uses single stepping? Initially the > debug trap shouldn't cause a VMEXIT, I think. That looks like a bug, indeed - it's missing from the initially set exception_bitmap. Could you check whether adding this in construct_vmcs() addresses that part of the issue? (A proper fix would likely include further adjustments to the setting of this flag, e.g. clearing it alongside clearing the DR intercept.) But then again all of this already depends on cpu_has_monitor_trap_flag - if that's set on your system, maybe you could try suppressing its detection (by removing CPU_BASED_MONITOR_TRAP_FLAG from the optional feature set in vmx_init_vmcs_config())? > And I'm not sure the > hypervisor will see a guest setting TF via an IRET. It shouldn't need to know of this. Jan