All of lore.kernel.org
 help / color / mirror / Atom feed
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/




      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.