Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1044774rwb; Fri, 23 Sep 2022 07:32:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4qekGBunT8Y+ldveJru1uTHmP2j2cg0YnBlmJGGg4/XZGAJBwb6ceBMwdMCKTvP4EdK87w X-Received: by 2002:a05:6402:5110:b0:450:c196:d7b1 with SMTP id m16-20020a056402511000b00450c196d7b1mr8845925edd.117.1663943570812; Fri, 23 Sep 2022 07:32:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663943570; cv=none; d=google.com; s=arc-20160816; b=Qzc4+Grnt67ql4QNh7wfhpniGForqrCJ3Qn19EP92UrcOE8f+jChZrYX+U6nnI72HE b2rS+XZ4SGJ7/hLScgln6apwT1U2VkguUXGi3hvF9V8blgDKdz6saSCli8M/wjZLufzp ExUUnE9Gh5Ge5OcrLZ3vVzoIWAXqeBdRoczaZhCwTAcRMz3v8AD0eZTJlpHDkyzz3bO4 f3Xm+iCFRkp3iSxFz5WfI3SxfEfWbY141CbBG17CkP8msy22YHhSRP1SLDzGjmf5LeB4 6zqSTLXAZgtSvJmdZVwnpFyzyDy4DvxBzD9a/iVGHDpvTWfygOPm4cOoD+CVEjilzEJU VDUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=IkszcL+rtnH8DHa1dQj8KCRG0Ns0Rh5p+ha/ZHCgI+Y=; b=oRQYEG/BbHdrMVqIAsz6zkOJCR/qAepWPJLcClmAQ8bQuw58DJ9h9SHIdDuHYDDZxa wqjiS47zbxkaF09DN5l2r4P9xIT1wNOQB/OavqSdiZa2w8gZyVz2vPbVK1zbPdAKf+5d Ek4XMbyMWUnYTeO+HCnPZf/t5ADDS9+SQIQnSiEw049CpQbf9ya/PNBUpNDFLgpDsWgK TwaQVL3Dl8y4g/Hbxt0K7fiSj/8Y+NQhDq7bZKLhS2mA4vESrPAUoENpbMVnnjS9gVjZ 8EPZijaPNgg+mhHP3TWWxvRtcCD+W9xRfvVUlXVcAjqrhtowvCIfK+xpgVjQ2zCuIHfG EZiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=no2i8Cja; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sb1-20020a1709076d8100b007722ccbc1e2si68985ejc.429.2022.09.23.07.32.16; Fri, 23 Sep 2022 07:32:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=no2i8Cja; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232578AbiIWOSu (ORCPT + 99 others); Fri, 23 Sep 2022 10:18:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232593AbiIWOSr (ORCPT ); Fri, 23 Sep 2022 10:18:47 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 766531296A1 for ; Fri, 23 Sep 2022 07:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663942726; x=1695478726; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=2ZW7KOwhuGX8/vjus2UIoe6mKHPYuInZCvASKmTZu1I=; b=no2i8CjaoPZcsWUelYPEzTXxHEHTyInYaLGiLeihSNmpUy/f0by2mR56 AyqOp6PH0z9EorhJopO4XVRp4JmwxlVicfzsi2srSQri+e6rtdPbHYS0C KmFmBHbBs61lLNfBt592zTfCnc1gYKXxhdl9643lwWggEhYikbpr8XtKr m9NwbgamIroyCajFPNnmdGjf3ZPqcIJysK3A5UnASR8wFfia4x0UJxuR7 R2kjBKgKYjjO/gcq2CY73j2XYQhCFuPsQFiI0UMxYx/oWJcEQMcmiHTMl tAKNFDfoKYThIkrorqERhCWVUk5fkUUxCn0of6oumG3CjFTBz725C8MwM w==; X-IronPort-AV: E=McAfee;i="6500,9779,10479"; a="280964983" X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="280964983" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 07:18:46 -0700 X-IronPort-AV: E=Sophos;i="5.93,339,1654585200"; d="scan'208";a="865306263" Received: from hanjulee-mobl1.amr.corp.intel.com (HELO [10.252.138.32]) ([10.252.138.32]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2022 07:18:43 -0700 Message-ID: Date: Fri, 23 Sep 2022 07:18:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling Content-Language: en-US To: Jason Gunthorpe , "Kirill A. Shutemov" Cc: Ashok Raj , Jacob Pan , "Kirill A. Shutemov" , Ashok Raj , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joerg Roedel References: <20220914165116.24f82d74@jacob-builder> <20220915090135.fpeokbokkdljv7rw@box.shutemov.name> <20220915172858.pl62a5w3m5binxrk@box.shutemov.name> <562dec4d-a39f-b517-58a3-45f691a2d10a@intel.com> <20220923004239.ma2gfrmoezsff4ro@box.shutemov.name> <20220923093826.kjad4qe3clwybeh6@box.shutemov.name> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/23/22 04:46, Jason Gunthorpe wrote: > On Fri, Sep 23, 2022 at 12:38:26PM +0300, Kirill A. Shutemov wrote: >>> So I would assume an untagged pointer should just be fine for the IOMMU >>> to walk. IOMMU currently wants canonical addresses for VA. >> Right. But it means that LAM compatibility can be block on two layers: >> IOMMU and device. IOMMU is not the only HW entity that has to be aware of >> tagged pointers. > Why does a device need to care about this? What do you imagine a > device doing with it? > > The userspace should program the device with the tagged address, the > device should present the tagged address on the bus, the IOMMU should > translate the tagged address the same as the CPU by ignoring the upper > bits. Is this how *every* access works? Every single device access to the address space goes through the IOMMU? I thought devices also cached address translation responses from the IOMMU and stashed them in their own device-local TLB. If the device is unaware of the tags, then how does device TLB invalidation work? Would all device TLB flushes be full flushes of the devices TLB? If something tried to use single-address invalidation, it would need to invalidate every possible tag alias because the device wouldn't know that the tags *are* tags instead of actual virtual addresses.