[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Debug-Registers in HVM domain destroyed


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Tue, 18 Feb 2014 13:48:09 +0100
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 18 Feb 2014 12:48:16 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type; b=IWlIM03SQxF7oLeMfaigdQJZu7ij1hCN/+kGe2BYqNWgGRTTiUqvppUo idcimvCWXZhDRUuk7d11Z0PbAOKcETK9Yzyeq3C15qCnE9cJ7Sp056GFF ORJ39schtKGR0fSZvwF59GkhDadekc0LJxnk8cubgRcQxSWlm4LT57Gm+ mzPv+MZfLl1iAjLUljrrIxT4jh7lVZbGv1ZjOmaXinBFCkAQ9RlfW3MED RcqUGynFJhrEKPyh79+v1OQ9GnJEx;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 14.02.2014 14:02, Jan Beulich wrote:
On 14.02.14 at 13:18, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote:
On 14.02.2014 11:40, Jan Beulich wrote:
On 14.02.14 at 10:33, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> 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

Okay, db0-3 seem to be preserved. I did a test modifying the registers without
activating any debug traps. Even under heavy vcpu scheduling load everything
was fine.


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.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 62060 2932
Fujitsu                                   e-mail: juergen.gross@xxxxxxxxxxxxxx
Mies-van-der-Rohe-Str. 8                Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Attachment: single-step.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.