From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corneliu ZUZU Subject: Re: [PATCH 7/7] arch.monitor: move bits to common (arch_domain to domain) Date: Tue, 9 Feb 2016 09:14:43 +0200 Message-ID: <56B991E3.4020508@bitdefender.com> References: <1454950682-9459-1-git-send-email-czuzu@bitdefender.com> <1454950682-9459-8-git-send-email-czuzu@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2384693101684151834==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tamas K Lengyel Cc: Kevin Tian , Keir Fraser , Ian Campbell , Razvan Cojocaru , Andrew Cooper , Xen-devel , Jan Beulich , Stefano Stabellini , Jun Nakajima List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============2384693101684151834== Content-Type: multipart/alternative; boundary="------------000108080803010603020409" This is a multi-part message in MIME format. --------------000108080803010603020409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/8/2016 8:29 PM, Tamas K Lengyel wrote: > > > On Mon, Feb 8, 2016 at 9:58 AM, Corneliu ZUZU > wrote: > > This patch moves bitfield members for single-step, > software-breakpoint and > guest-request monitor vm-events from the arch-side (struct > arch_domain) to > the common-side (struct domain). Ctrl-reg bits (i.e. > write_ctrlreg_* members) > are left on the arch-side, because control-registers number can > vary across > architectures. > > Signed-off-by: Corneliu ZUZU > > > > Technically this looks fine, but I do wonder if and what plans you > have to actually implement these events for ARM. Currently I've only planned implementations for control-register write events & guest-requests. The other two also seem feasible though, I might give adding those a shot sometime after sending the other patches. > I haven't spent too much time looking into it, but I'm not aware of > equivalent features on ARM to Intel MTF (singlestepping) or to > software-breakpoint trapping. The only instruction I know that > functionally comes close to software-breakpoint trapping (INT3) is the > SMC instruction which can be trapped into the VMM, but I would not > call that a "breakpoint" in the traditional sense. > > Tamas > There's the debugging architecture, hypervisor control of that is possible on both 32-bit & 64-bit ARM. It isn't as easy as for X86 though, where MTF is a hypervisor-internal feature and INT3 can be trapped specifically, whereas on ARM granularity of trap-setting is less of a concern apparently. For this reason, the only issue I see here is the performance penalty these traps would cause for arbitrary software breakpoints (for obvious reasons that doesn't matter in the case of single-stepping). For INT3, the ARM equivalent is be the BKPT/BRK (set HDCR.TDE on AArch32/MDCR_EL2.TDE AArch64) instruction. Trapping on this instruction implies trapping on - AArch32: some other debug exceptions (looking @ B1.8.9, ARMv7 DDI 0406C.b) - AArch64: *all software debug exceptions* + *all debug register accesses* (this might cause some headaches) For MTF-like functionality, the debug architecture also provides ways for single-stepping. That would similarly generate software breakpoint exceptions which can be routed to the hypervisor. Corneliu. --------------000108080803010603020409 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 2/8/2016 8:29 PM, Tamas K Lengyel wrote:


On Mon, Feb 8, 2016 at 9:58 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
This patch moves bitfield members for single-step, software-breakpoint and
guest-request monitor vm-events from the arch-side (struct arch_domain) to
the common-side (struct domain). Ctrl-reg bits (i.e. write_ctrlreg_* members)
are left on the arch-side, because control-registers number can vary across
architectures.

Signed-off-by: Corneliu ZUZU <czuzu@bitdefender.com>

Technically this looks fine, but I do wonder if and what plans you have to actually implement these events for ARM.

Currently I've only planned implementations for control-register write events & guest-requests.
The other two also seem feasible though, I might give adding those a shot sometime after sending the other patches.

I haven't spent too much time looking into it, but I'm not aware of equivalent features on ARM to Intel MTF (singlestepping) or to software-breakpoint trapping. The only instruction I know that functionally comes close to software-breakpoint trapping (INT3) is the SMC instruction which can be trapped into the VMM, but I would not call that a "breakpoint" in the traditional sense.

Tamas


There's the debugging architecture, hypervisor control of that is possible on both 32-bit & 64-bit ARM.
It isn't as easy as for X86 though, where MTF is a hypervisor-internal feature and INT3 can be
trapped specifically, whereas on ARM granularity of trap-setting is less of a concern apparently.
For this reason, the only issue I see here is the performance penalty these traps would cause for
arbitrary software breakpoints (for obvious reasons that doesn't matter in the case of single-stepping).

For INT3, the ARM equivalent is be the BKPT/BRK (set HDCR.TDE on AArch32/MDCR_EL2.TDE AArch64) instruction.
Trapping on this instruction implies trapping on
- AArch32: some other debug exceptions (looking @ B1.8.9, ARMv7 DDI 0406C.b)
- AArch64: *all software debug exceptions* + *all debug register accesses* (this might cause some headaches)
For MTF-like functionality, the debug architecture also provides ways for single-stepping.
That would similarly generate software breakpoint exceptions which can be routed to the hypervisor.

Corneliu.
--------------000108080803010603020409-- --===============2384693101684151834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2384693101684151834==--