From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39984 invoked by alias); 25 Apr 2018 00:09:50 -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 39964 invoked by uid 89); 25 Apr 2018 00:09:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f193.google.com Received: from mail-ot0-f193.google.com (HELO mail-ot0-f193.google.com) (74.125.82.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Apr 2018 00:09:48 +0000 Received: by mail-ot0-f193.google.com with SMTP id j27-v6so23224731ota.5 for ; Tue, 24 Apr 2018 17:09:48 -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=bmMfSeRaueUbnNdGiuxV53JpaTsPUjS56joLodMzfIM=; b=gFylEfGz/o/na3XtKJ8HmwBc2VbRPoewDYDPmxyX0U91CGYBJjNuo0hUrEibdOSMD4 iMghBQDPbIGvdGMRv0wwnYpwTL3ebtysUIq6v2NV7YFAXZ1/VeEwM6+O7MSB2WHBA4YY btOAntmUaPAo2F4HLWTXC4CJdonms9zoRTQbdJh8EijhHA3PT8m2qW0CaLWKBcxFJ1af ImK7FhBUN8rK8rW6MkqKZu4s0koGbLi3xY8x9c11n69ZzIQ7UwwmRGdnf2rbnNUHphCQ u2+V6Gb/De2VgRi5RW6MQuz36oE0eue3L8f2VdHBjLjmtkV+FRSQSB/GlP+mHW/E+PmQ gCsw== X-Gm-Message-State: ALQs6tB9iH7O1GedDy9G4AZjOo5QHXokcImjoVwuqXqTeDkcKkIQe1fo 027+YoPPHDwyxFN4UJIa9+jPJGWI50BI9uegDZc= X-Google-Smtp-Source: AB8JxZq0eJ99RsZFfsjL+wOlk7eGMTzCNRp+3dxtNyHPqSI57RbvOrGl3/nCZWI+D9GSu/xE5eaOQnNR7E8TjVe7REI= X-Received: by 2002:a9d:14c5:: with SMTP id r5-v6mr1159608otr.397.1524614986546; Tue, 24 Apr 2018 17:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:3644:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 17:09:46 -0700 (PDT) In-Reply-To: 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: Andrew Pinski Date: Wed, 25 Apr 2018 00:09:00 -0000 Message-ID: Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer To: Omair Javaid Cc: Daniel Thompson , Pedro Alves , Yao Qi , GDB Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-04/txt/msg00498.txt.bz2 On Tue, Apr 24, 2018 at 4:41 PM, Omair Javaid wrote: > 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? YES. 52bit VA userspace addresses are coming soon. Thanks, Andrew > > This actually means we wont need any set pointer-tagging command and > can modify existing implementation. Sounds good? > >> >> >> Daniel.