All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: Single step in HVM domU on Intel machine may see wrong DB6
Date: Wed, 05 Mar 2014 07:02:04 +0100	[thread overview]
Message-ID: <5316BDDC.9020000@ts.fujitsu.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0A9FDD11@SHSMSX104.ccr.corp.intel.com>

On 05.03.2014 03:22, Zhang, Yang Z wrote:
> Jan Beulich wrote on 2014-02-27:
>>>>> On 27.02.14 at 02:31, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
>>> Jan Beulich wrote on 2014-02-27:
>>>>>>> On 26.02.14 at 06:15, "Zhang, Yang Z" <yang.z.zhang@intel.com>
>> wrote:
>>>>> @@ -2690,9 +2688,13 @@ void vmx_vmexit_handler(struct
>> cpu_user_regs
>>>> *regs)
>>>>>               __vmread(EXIT_QUALIFICATION, &exit_qualification);
>>>>>               HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>>>>>               write_debugreg(6, exit_qualification | 0xffff0ff0);
>>>>> -            if ( !v->domain->debugger_attached ||
>>>>> cpu_has_monitor_trap_flag ) -                goto exit_and_crash; -
>>>>>         domain_pause_for_debugger(); +            if (
>>>>> v->domain->debugger_attached ) +
>>>>> domain_pause_for_debugger(); +            else +            { +
>>>>>         __restore_debug_registers(v); +
>>>>> hvm_inject_hw_exception(TRAP_debug,
>> HVM_DELIVER_NO_ERROR_CODE); +
>>>>>       }
>>>>
>>>> I suppose you need to set DR6.BS after restoring the reigsters?
>>>
>>> Right but is not enough. If flag_dr_dirty is set, we need to restore
>>> register from hardware. Conversely, restore is from debugreg and set
>>> DR6 to exit_qualification.
>>
>> After some more thought, I in fact doubt that restoring the debug
>> registers is in line with the current model: We should simply set
>> DR6.BS in the in-memory copy when the debug registers aren't live yet
>> (and it doesn't hurt to always do that). And since DR6 bits generally
>> are sticky, I think exit_qualification actually needs to be or-ed into the in-memory copy.
>
> Will guest be confused to see the DR6.BS always set?

You can't set DR6.BS unconditionally! This bit should be set only in case
of a debug trap caused by single stepping, of course!

At least our BS2000 domU will crash in case of an unmotivated DR6.BS in debug
trap handling.


Juergen

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

  reply	other threads:[~2014-03-05  6:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20  8:36 Single step in HVM domU on Intel machine may see wrong DB6 Juergen Gross
2014-02-21  1:26 ` Zhang, Yang Z
2014-02-21  5:36   ` Juergen Gross
2014-02-26  5:15     ` Zhang, Yang Z
2014-02-26 16:00       ` Jan Beulich
2014-02-27  1:31         ` Zhang, Yang Z
2014-02-27  8:09           ` Jan Beulich
2014-03-05  2:22             ` Zhang, Yang Z
2014-03-05  6:02               ` Juergen Gross [this message]
2014-03-05  8:05               ` Jan Beulich
2014-03-07  5:10                 ` Zhang, Yang Z
2014-03-07  9:12                   ` Jan Beulich
2014-03-11  2:10                     ` Zhang, Yang Z
2014-03-11  7:56                       ` Jan Beulich
2014-03-11  8:04                         ` Zhang, Yang Z
2014-03-11  2:40                     ` Zhang, Yang Z
2014-05-06  5:17                   ` Juergen Gross
2014-05-06  6:20                     ` Zhang, Yang Z
2014-03-04 15:06       ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5316BDDC.9020000@ts.fujitsu.com \
    --to=juergen.gross@ts.fujitsu.com \
    --cc=JBeulich@suse.com \
    --cc=eddie.dong@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.