From: Tamas K Lengyel <tamas@tklengyel.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Wei Liu <wei.liu2@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
Razvan Cojocaru <rcojocaru@bitdefender.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v4 8/8] x86/vm_event: Add HVM debug exception vm_events
Date: Wed, 1 Jun 2016 18:01:15 -0600 [thread overview]
Message-ID: <CABfawh=k0xKvg3qPRiLF78S4XmTnQQBR7Uqs4QT_t7bX+B3hpw@mail.gmail.com> (raw)
In-Reply-To: <05a98321-f49d-6709-b6ff-5237ca17ca1e@citrix.com>
On Wed, Jun 1, 2016 at 4:17 PM, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 01/06/2016 22:46, Tamas K Lengyel wrote:
>> On Tue, May 31, 2016 at 1:59 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 30.05.16 at 22:13, <tamas@tklengyel.com> wrote:
>>>> On Mon, May 30, 2016 at 8:16 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>> On 30.05.16 at 00:37, <tamas@tklengyel.com> wrote:
>>>>>> @@ -3393,8 +3409,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>>>>> }
>>>>>> else {
>>>>>> int handled =
>>>>>> - hvm_monitor_breakpoint(regs->eip,
>>>>>> - HVM_MONITOR_SOFTWARE_BREAKPOINT);
>>>>>> + hvm_monitor_debug(regs->eip,
>>>>>> + HVM_MONITOR_SOFTWARE_BREAKPOINT,
>>>>>> + X86_EVENTTYPE_SW_EXCEPTION, 1);
>>>>> Please let's not add further mistakes like this, assuming INT3 can't
>>>>> have any prefixes. It can, even if they're useless.
>>>> You mean the instruction length is not necessarily 1? Ultimately it
>>>> doesn't seem to matter because reinjecting it with xc_hvm_inject_trap
>>>> ignores this field. Instruction length is only required to be properly
>>>> set AFAICT for a subset of debug exceptions during reinjection.
>>> As you suggest later in your reply, if the insn length really doesn't
>>> matter, this should be made recognizable here. Either by a suitably
>>> named manifest constant (which could then even evaluate to zero),
>>> or by a comment (personally I'd prefer the former, but I'm not
>>> maintainer of this code).
>>>
>>> Jan
>>
>> Running Andrew's framework with xen-access monitoring breakpoints results in
>>
>> xen-access:
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>>
>> xl dmesg:
>> (d28) --- Xen Test Framework ---
>> (d28) Environment: HVM 64bit (Long mode 4 levels)
>> (d28) Trap emulation
>> (d28) Warning: FEP support not detected - some tests will be skipped
>> (d28) Test cpl0: all perms ok
>> (d28) Testing int3
>> (XEN) d28v0 VMRESUME error: 0x7
>> (XEN) domain_crash_sync called from vmcs.c:1599
>> (XEN) Domain 28 (vcpu#0) crashed on cpu#7:
>> (XEN) ----[ Xen-4.6.1 x86_64 debug=n Not tainted ]----
>> (XEN) CPU: 7
>> (XEN) RIP: 0008:[<00000000001032d1>]
>> (XEN) RFLAGS: 0000000000000046 CONTEXT: hvm guest (d28v0)
>> (XEN) rax: 00000000001032d2 rbx: 00000000001102b0 rcx: 0000000000000000
>> (XEN) rdx: 0000000000104af0 rsi: 0000000000000000 rdi: 0000000000000000
>> (XEN) rbp: 0000000000000001 rsp: 0000000000114f98 r8: 000000000000000f
>> (XEN) r9: 00000000000000ad r10: 000000000000000f r11: 0000000000000004
>> (XEN) r12: 0000000000000003 r13: 0000000000000000 r14: 0000000000000000
>> (XEN) r15: 0000000000000000 cr0: 0000000080000011 cr4: 0000000000000020
>> (XEN) cr3: 000000000010b000 cr2: 0000000000000000
>> (XEN) ds: 0033 es: 0033 fs: 0033 gs: 0033 ss: 0000 cs: 0008
>>
>> This is likely because xen-access sets the instruction length to 0
>> during reinjection. If I change that to 1 the tests still fail but
>> without crashing the domain, output:
>>
>> xen-access:
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e2, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e2, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032d1, gfn=103 (vcpu 0)
>> Got event from Xen
>> Breakpoint: rip=00000000001032e1, gfn=103 (vcpu 0)
>>
>> xl dmesg:
>> (d30) Environment: HVM 64bit (Long mode 4 levels)
>> (d30) Trap emulation
>> (d30) Warning: FEP support not detected - some tests will be skipped
>> (d30) Test cpl0: all perms ok
>> (d30) Testing int3
>> (d30) Fail redundant: Expected 1 exception (vec 3 at 00000000001032e3), got 2
>> (d30) exlog[00] 0008:00000000001032e2 vec 3[0000]
>> (d30) exlog[01] 0008:00000000001032e3 vec 3[0000]
>> (d30) Testing int $3
>> (d30) Testing icebp
>> (d30) Testing int $1
>> (d30) Testing into
>> (d30) Test cpl0: p=0
>> (d30) Testing int3
>> (d30) Testing int $3
>> (d30) Testing icebp
>> (d30) Testing int $1
>> (d30) Testing into
>> (d30) Test cpl3: all perms ok
>> (d30) Testing int3
>> (d30) Fail redundant: Expected 1 exception (vec 3 at 00000000001032e3), got 2
>> (d30) exlog[00] 0023:00000000001032e2 vec 3[0000]
>> (d30) exlog[01] 0023:00000000001032e3 vec 3[0000]
>> (d30) Testing int $3
>> (d30) Testing icebp
>> (d30) Testing int $1
>> (d30) Testing into
>> (d30) Test cpl3: p=0
>> (d30) Testing int3
>> (d30) Testing int $3
>> (d30) Testing icebp
>> (d30) Testing int $1
>> (d30) Testing into
>> (d30) Test cpl3: dpl=0
>> (d30) Testing int3
>> (d30) Testing int $3
>> (d30) Testing icebp
>> (d30) Testing int $1
>> (d30) Testing into
>> (d30) Test result: FAILURE
>>
>> So we _should be_ sending the instruction length information along for
>> this type of vm_events and it is in fact buggy right now.
>
> On a related note, do emulated instruction get appropriately sent for
> introspection?
I'm fairly certain emulated int3 is not forwarded through vm_event as
the only hook we have right now for int3 comes from vmx.c.
>
> You can check this by booting a debug hypervisor with "hvm_fep" on the
> command line, which will double the number of tests run by this suite.
>
> If they are sent for emulation, you would expect to see some "Fail force
> redundant:" issues as well. I can't think of any codepath offhand which
> links the emulation results up to the current introspection paths.
I'll try it out, thanks!
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-06-02 0:01 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-29 22:37 [PATCH v4 1/8] monitor: Rename vm_event_monitor_get_capabilities Tamas K Lengyel
2016-05-29 22:37 ` [PATCH v4 2/8] monitor: Rename vm_event_monitor_guest_request Tamas K Lengyel
2016-05-30 7:05 ` Razvan Cojocaru
2016-05-30 13:51 ` Jan Beulich
2016-05-29 22:37 ` [PATCH v4 3/8] monitor: Rename hvm/event to hvm/monitor Tamas K Lengyel
2016-05-30 7:08 ` Razvan Cojocaru
2016-05-30 13:53 ` Jan Beulich
2016-05-29 22:37 ` [PATCH v4 4/8] monitor: ARM SMC events Tamas K Lengyel
2016-06-01 11:37 ` Julien Grall
[not found] ` <CABfawhmO9tUG3-OcorfwqdOgZTkjoUk+u=dHySGonBDvobqyKw@mail.gmail.com>
[not found] ` <CABfawhmK2GAmQqZMhrgjYzeUZ_XaoyRUPuJxyPK5LJEHwsp5SA@mail.gmail.com>
[not found] ` <CABfawh=J1fwinTYKGvJNrFPOsGLSXz6U3GE8fxPz3-KsXSWfbQ@mail.gmail.com>
[not found] ` <CABfawhn7zvE=hn0hq1ryH+sW-jdkAXgZM1C2KxwZVUE8pbp8cQ@mail.gmail.com>
2016-06-01 15:41 ` Tamas K Lengyel
2016-06-02 14:23 ` Julien Grall
2016-06-02 22:31 ` Tamas K Lengyel
2016-07-04 19:13 ` Tamas K Lengyel
2016-07-04 20:02 ` Julien Grall
2016-07-04 21:05 ` Tamas K Lengyel
2016-07-05 9:58 ` Julien Grall
2016-05-29 22:37 ` [PATCH v4 5/8] arm/vm_event: get/set registers Tamas K Lengyel
2016-05-30 7:09 ` Razvan Cojocaru
2016-05-30 11:50 ` Jan Beulich
2016-05-30 19:47 ` Tamas K Lengyel
2016-05-30 20:20 ` Julien Grall
2016-05-30 20:37 ` Tamas K Lengyel
2016-05-30 20:46 ` Razvan Cojocaru
2016-05-30 20:53 ` Tamas K Lengyel
2016-05-30 21:35 ` Julien Grall
2016-05-30 21:41 ` Tamas K Lengyel
2016-05-31 7:54 ` Jan Beulich
2016-05-31 8:06 ` Razvan Cojocaru
2016-05-31 8:30 ` Jan Beulich
2016-05-31 16:20 ` Tamas K Lengyel
2016-05-31 7:48 ` Jan Beulich
2016-05-31 16:28 ` Tamas K Lengyel
2016-06-01 8:41 ` Jan Beulich
2016-06-01 11:24 ` Julien Grall
2016-06-01 18:21 ` Tamas K Lengyel
2016-06-01 19:34 ` Razvan Cojocaru
2016-06-01 19:43 ` Julien Grall
2016-06-02 7:35 ` Jan Beulich
2016-06-02 8:26 ` Razvan Cojocaru
2016-06-02 9:38 ` Jan Beulich
2016-06-02 9:42 ` Razvan Cojocaru
2016-06-01 19:38 ` Julien Grall
2016-06-01 19:49 ` Julien Grall
2016-06-01 19:50 ` Tamas K Lengyel
2016-05-29 22:37 ` [PATCH v4 6/8] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
2016-05-29 22:37 ` [PATCH v4 7/8] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
2016-05-30 9:56 ` Wei Liu
2016-05-29 22:37 ` [PATCH v4 8/8] x86/vm_event: Add HVM debug exception vm_events Tamas K Lengyel
2016-05-30 7:29 ` Razvan Cojocaru
2016-05-30 14:16 ` Jan Beulich
2016-05-30 20:13 ` Tamas K Lengyel
2016-05-30 20:58 ` Andrew Cooper
2016-05-31 7:59 ` Jan Beulich
2016-06-01 21:46 ` Tamas K Lengyel
2016-06-01 22:17 ` Andrew Cooper
2016-06-02 0:01 ` Tamas K Lengyel [this message]
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='CABfawh=k0xKvg3qPRiLF78S4XmTnQQBR7Uqs4QT_t7bX+B3hpw@mail.gmail.com' \
--to=tamas@tklengyel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=rcojocaru@bitdefender.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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.