qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly


From: Rémi Denis-Courmont
Subject: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly
Date: Fri, 13 Mar 2020 15:59:29 +0200

        Hello,

The following changes since commit d4f7d56759f7c75270c13d5f3f5f736a9558929c:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200312' 
into staging (2020-03-12 17:34:34 +0000)

adds support for the ARM MTE compatibility subset (which does not seem to have
an official name) to QEMU user mode and system mode on "max" CPU. This
corresponds to MTE == 1 in the instruction set feature field, and allows
running code with MTE instructions without actual tag storage.

Similar to the SP alignment checks, it also adds stubs for memory tag checks
that don't actually do anything at this point and would be optimized out by
the compiler.

For proper storage and checking of memory tags, MTE == 2 would be
necessary. I have some code (on top of this RFC but not included) to add the
tag allocation logic. But I have no clue how to actually store the tags in QEMU
system mode at this point, so it's mostly dead code.

In user mode, it seems impossible anyway, as tags are indexed by physical, not
virtual address and QEMU cannot know which virtual memory address may
physically alias another within the user process.

----------------------------------------------------------------
Rémi Denis-Courmont (5):
      target/arm: MTE processor state
      target/arm: MTE user mode disassembly
      target/arm: MTE unprivileged system mode disassembly
      target/arm: MTE privileged system mode assembly
      target/arm: MTE tag check stubs

 target/arm/cpu.h           |  17 +++
 target/arm/cpu64.c         |   5 +
 target/arm/helper-a64.c    |   2 +
 target/arm/helper.c        | 118 +++++++++++++++
 target/arm/translate-a64.c | 370 ++++++++++++++++++++++++++++++++++++++++++---
 5 files changed, 494 insertions(+), 18 deletions(-)

-- 
Реми Дёни-Курмон
http://www.remlab.net/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]