From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Debug-Registers in HVM domain destroyed Date: Tue, 18 Feb 2014 12:56:24 +0000 Message-ID: <53036688020000780011D4B5@nat28.tlf.novell.com> References: <52FDE2ED.4030008@ts.fujitsu.com> <52FE00C8020000780011C649@nat28.tlf.novell.com> <52FE09A2.4000909@ts.fujitsu.com> <52FE21E4020000780011C6F5@nat28.tlf.novell.com> <53035689.4000602@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFkDy-00064e-87 for xen-devel@lists.xenproject.org; Tue, 18 Feb 2014 12:56:34 +0000 In-Reply-To: <53035689.4000602@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 18.02.14 at 13:48, Juergen Gross wrote: > On 14.02.2014 14:02, Jan Beulich wrote: >>>>> On 14.02.14 at 13:18, Juergen Gross wrote: >>> 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())? > > I've currently a test running with the attached patch (the bug was hit about > once every 3 hours, test is running now for about 4 hours without problem). > Test machine is running with Xen 4.2.3 hypervisor from SLES11 SP3. Which, if it continues running fine, would confirm the theory. I'd like to defer to the VMX folks though for putting together a proper fix then - I'd likely overlook some corner case. Jan