From: "Rémi Denis-Courmont" <remi@remlab.net>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly
Date: Fri, 13 Mar 2020 18:05:44 +0200 [thread overview]
Message-ID: <2232346.Qcd0NKbubf@basile.remlab.net> (raw)
In-Reply-To: <886d0295-9fed-2e81-ce5e-54668755029e@linaro.org>
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/
prev parent reply other threads:[~2020-03-13 16:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 13:59 [RFC] [PATCH 0/5] ARMv8.5-MemTag disassembly Rémi Denis-Courmont
2020-03-13 14:00 ` Rémi Denis-Courmont
2020-03-13 14:03 ` Peter Maydell
2020-03-13 15:16 ` Rémi Denis-Courmont
2020-03-13 15:19 ` Peter Maydell
2020-03-13 15:49 ` Richard Henderson
2020-03-13 16:05 ` Rémi Denis-Courmont [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=2232346.Qcd0NKbubf@basile.remlab.net \
--to=remi@remlab.net \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.