qemu-arm
[Top][All Lists]
Advanced

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

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


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

Le perjantaina 13. maaliskuuta 2020, 17.49.06 EET Richard Henderson a écrit :
> On 3/13/20 6:59 AM, Rémi Denis-Courmont wrote:
> > 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.
> 
> I have implemented this, and posted version 6 yesterday.
> Peter gave you the link.

Yes, I'm sure it's feasible on the system mode. Physical indexing is not a 
problem there.

> > 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.
> 
> When I update my mte user branch, I will only support anonymous memory,
> since I cannot share my on-the-side data structure for tags between
> aarch64-linux-user processes, whether or not they are in a tmpfs
> filesystem.

Oh, absolutely: if you only support anonymous memory, then the user mode case 
is easy as you can index tags on virtual address - much easier than system 
mode in all likelihood. I already had kludgy implementation of that a year 
ago, but that was not in a level of code quality that I'd ever submit publicly 
to an OSS project. It works fine as long as there's no named mappings in the 
tested code. My point was *only* that I can't think of a reasonable way to 
implement user mode *correctly*, no more.

And given that it was neither correct nor fast, it seemed doubly questionable 
in QEMU. AFAIU, QEMU tries to optimize for speed anyway (hence that it does 
not trigger SP alignment exception, for instance).

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/






reply via email to

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