From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5137 invoked by alias); 24 Apr 2018 23:42:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5126 invoked by uid 89); 24 Apr 2018 23:42:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qk0-f196.google.com Received: from mail-qk0-f196.google.com (HELO mail-qk0-f196.google.com) (209.85.220.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Apr 2018 23:42:13 +0000 Received: by mail-qk0-f196.google.com with SMTP id p186so18464595qkd.1 for ; Tue, 24 Apr 2018 16:42:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kS598+OYkwOAbPEOrWm9JlMjt82CTRnsjl+W40iy3ZE=; b=mcWZHV+XVQGr7kYYxWCPKNyG7X5TCL8BXvrLGYKXQgDudSTHepjE2AguW8CQ3jw40h Sj/i7hTUBLcit+Sw8zmeS7PY4qDYQkIBw2mDgmaaoZuMW4yaNLIyCuLy7qKQBV3RCh3s uHFQgx9bNGwteNn/wzLGdw/9bUBdQOJ9cw8c5KXtnA3OrEcK2buQmsW8AB66QO7qADjA SyXUeGB3D+olaA7yfdQPiqTJhvXIZ9/LXoPjAL6RtI0YMqnRNvi830bdUWOXSqtLpyJT krpVKdMZ/N4p1VnSVTnK3HGxIBv/7TKW/sPzHQ9p6y5/g+pAG4MaMFuMR9ObquCklux/ jbGA== X-Gm-Message-State: ALQs6tAa70DuYVmqvIW2BbMASUXojv4xJ9Rbewh3u68kjBVNOEoykoSU K7u7KmVxbMQ51KPecw6iwH2lHYTES8WnfUUajVSjJA== X-Google-Smtp-Source: AB8JxZpdz4r2LYUC449hqjmnvGcHbSxVVGsM8yTfnof5+xZOZ0X/jVtHd5d4mWvZVQTDKnAvmBqhVLQj1n86h+18AfI= X-Received: by 10.55.72.79 with SMTP id v76mr29505770qka.193.1524613331153; Tue, 24 Apr 2018 16:42:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.39.46 with HTTP; Tue, 24 Apr 2018 16:41:40 -0700 (PDT) In-Reply-To: <20180424160538.kxvorrhvku4ukpj6@holly.lan> References: <5429b7f0-ee91-67f4-3b15-f5de9aa06389@redhat.com> <5e21c13b-9261-f947-e06c-dad9568278bf@redhat.com> <061e956c-72a7-2c2e-512b-3dfe42881818@redhat.com> <56373ed6-3a63-4508-61fa-54a3a456d785@redhat.com> <3f62b4ea-1f80-5faa-f372-b83b3e5de448@redhat.com> <20180424160538.kxvorrhvku4ukpj6@holly.lan> From: Omair Javaid Date: Tue, 24 Apr 2018 23:42:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Daniel Thompson Cc: Pedro Alves , Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00497.txt.bz2 On 24 April 2018 at 21:05, Daniel Thompson wrote: > On Tue, Apr 24, 2018 at 12:48:19PM +0100, Pedro Alves wrote: >> Hi, >> >> On 04/20/2018 03:33 PM, Omair Javaid wrote: >> >> > Pointer tagging information is stored in MMU registers so in linux >> > user-space we cannot actually read if pointer tagging is enabled or not >> > based on register bits. >> > JTAG debuggers should be able to read MMU registers and know whether >> > pointer tagging is enabled or not. >> > >> > Rationale behind adding a separate command is to allow other application to >> > control pointer tagging for example bare-metal (non-linux OSes) which want >> > to use pointer tagging can enable it. I must admit I dont know of any such >> > use-case as of now. >> >> Alright, that's in line with what I was thinking. Though, bare metal >> should have access to MMU registers too. Ideally, things would Just Work >> without user intervention. But I don't mind starting by adding a >> user-controllable knob, it might be a convenient escape hatch. We can always >> extend it from "on/off" -> "on/off/auto" setting, with auto the default >> in future. > > For bare metal cases this is not a simple on/off control! > > Top byte ignore (a.k.a. pointer tagging) has separate on/off switches > for TTBR0 (0x0 upwards) and TTBR1 (0xffffffffffff downwards) *and* we > have to know the respective sizes of TTBR0 and TTBR1 to be sure which > table we are using. > > >> > Also I am not sure about the timeline of Linux Kernel patches going into >> > gdb and for now I thought of this command as the most suitable option. >> > Moreover some users might also be interested in combination where pointer >> > tagging is enabled but Linux Kernel threads support is disabled so I >> > thought we should give the control to the user in cases where we cannot >> > predict use-cases. >> >> If everyone agrees that proper Linux kernel support benefits from >> its own osabi setting/name, then I don't see why we couldn't start by >> adding the osabi setting as soon as we have a use for it, even if >> the larger Linux Kernel patches aren't ready yet. > > Following on from the above, for aarch64-linux-tdep we can apply domain > knowledge regarding how things are configured. Here we know that TTBR0 > is guaranteed to have top byte ignore set, TTBR1 does not *and* we > also know (from memory-layout.txt) that TTBR0 is sufficiently small > that bit 55 can be used to discriminate between the two cases. > > In others words regardless of whether we are running at EL0 or EL1 then > I think we should mask the top byte from pointers if and only if bit 55 > is unset, otherwise leave them as they are. What I am understanding here is that you are basing your decision on the fact that: "User addresses have bits 63:48 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address." Sounds legitimate for now but are we ever going to use more than 48-bit virtual addresses in arm64 linux? This actually means we wont need any set pointer-tagging command and can modify existing implementation. Sounds good? > > > Daniel.