Re: [PATCH 7/7] arch.monitor: move bits to common (arch_domain to domain)

[Corneliu ZUZU <czuzu@bitdefender.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2443 bytes --]

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 
> <mailto: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
>     <mailto: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.

[-- Attachment #1.2: Type: text/html, Size: 4170 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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