From: Alexandru Stefan ISAILA <aisaila@bitdefender.com>
To: "tamas@tklengyel.com" <tamas@tklengyel.com>
Cc: "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"rcojocaru@bitdefender.com" <rcojocaru@bitdefender.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"jbeulich@suse.com" <jbeulich@suse.com>,
"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v2] hvm/svm: Implement Debug events
Date: Tue, 20 Mar 2018 17:07:44 +0000 [thread overview]
Message-ID: <1521565664.3535.6.camel@bitdefender.com> (raw)
In-Reply-To: <CABfawhnWqkOCJcR5Xc5m2vpv8e27aBuokW_1u-kdvfvfWTTwqw@mail.gmail.com>
On Ma, 2018-03-20 at 10:49 -0600, Tamas K Lengyel wrote:
> On Tue, Mar 20, 2018 at 3:40 AM, Alexandru Isaila
> <aisaila@bitdefender.com> wrote:
> >
> > At this moment the Debug events for the AMD architecture are not
> > forwarded to the monitor layer.
> >
> > This patch adds the Debug event to the common capabilities, adds
> > the VMEXIT_ICEBP then forwards the event to the monitor layer.
> >
> > Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
> > exception generated by the single byte INT1
> > instruction (also known as ICEBP) does not trigger the #DB
> > intercept. Software should use the dedicated ICEBP
> > intercept to intercept ICEBP"
> >
> > ---
> > Changes since V1:
> > - Get inst_len from __get_instruction_length()
> > - Updated __get_instruction_length() for the INSTR_ICEBP
> > instruction
> >
> > Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> > ---
> > xen/arch/x86/hvm/svm/emulate.c | 1 +
> > xen/arch/x86/hvm/svm/svm.c | 37
> > +++++++++++++++++++++++++----------
> > xen/arch/x86/hvm/svm/vmcb.c | 2 +-
> > xen/include/asm-x86/hvm/svm/emulate.h | 1 +
> > xen/include/asm-x86/monitor.h | 4 ++--
> > 5 files changed, 32 insertions(+), 13 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/svm/emulate.c
> > b/xen/arch/x86/hvm/svm/emulate.c
> > index e1a1581..172369e 100644
> > --- a/xen/arch/x86/hvm/svm/emulate.c
> > +++ b/xen/arch/x86/hvm/svm/emulate.c
> > @@ -80,6 +80,7 @@ static const struct {
> > [INSTR_RDTSC] = { X86EMUL_OPC(0x0f, 0x31) },
> > [INSTR_RDMSR] = { X86EMUL_OPC(0x0f, 0x32) },
> > [INSTR_CPUID] = { X86EMUL_OPC(0x0f, 0xa2) },
> > + [INSTR_ICEBP] = { X86EMUL_OPC( 0, 0xf1) },
> > };
> >
> > int __get_instruction_length_from_list(struct vcpu *v,
> > diff --git a/xen/arch/x86/hvm/svm/svm.c
> > b/xen/arch/x86/hvm/svm/svm.c
> > index c34f5b5..d4f2290 100644
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1109,7 +1109,8 @@ static void noreturn svm_do_resume(struct
> > vcpu *v)
> > {
> > struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> > bool debug_state = (v->domain->debugger_attached ||
> > - v->domain-
> > >arch.monitor.software_breakpoint_enabled);
> > + v->domain-
> > >arch.monitor.software_breakpoint_enabled ||
> > + v->domain-
> > >arch.monitor.debug_exception_enabled);
> Please explain the rationale why this is included under
> "debug_exception" and not "software_breakpoint".
>
> Thanks,
> Tamas
>
Hi Tamas,
I've included the icebp under the debug_exception only to have
consistency with the vmx side. I saw this behavior after running
the swint-emulation from xtf.
Regards,
Alex
________________________
This email was scanned by Bitdefender
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-03-20 17:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 9:40 [PATCH v2] hvm/svm: Implement Debug events Alexandru Isaila
2018-03-20 15:53 ` Andrew Cooper
2018-03-20 16:05 ` Jan Beulich
2018-03-20 16:14 ` Andrew Cooper
2018-03-20 16:33 ` Alexandru Stefan ISAILA
2018-03-20 16:44 ` Jan Beulich
2018-03-20 16:49 ` Tamas K Lengyel
2018-03-20 16:57 ` Andrew Cooper
2018-03-20 17:07 ` Alexandru Stefan ISAILA [this message]
2018-03-20 18:28 ` Tamas K Lengyel
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=1521565664.3535.6.camel@bitdefender.com \
--to=aisaila@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=jbeulich@suse.com \
--cc=rcojocaru@bitdefender.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tamas@tklengyel.com \
--cc=xen-devel@lists.xen.org \
/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.