Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1520345ybx; Thu, 7 Nov 2019 13:05:06 -0800 (PST) X-Google-Smtp-Source: APXvYqxKjQ7wi5qzwoS6vSA9eUiGRGwe462qiX+rr4ljSeyi2WvtVHUHCZ/QFU4Zl+dA8hVvydyo X-Received: by 2002:a05:6402:110c:: with SMTP id u12mr6163765edv.127.1573160706613; Thu, 07 Nov 2019 13:05:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573160706; cv=none; d=google.com; s=arc-20160816; b=SSo6nEtGbrVZaXPPI7xSnc3oEmOKxJHMeHQeMyorpQJu2OrNHDHxxVOiscACcsN5vT GheM6BC0UtjH7JYYDECzS0iC2rOyCAsYThmhaqQU6L35I9pFP+Orifbo1Bdwyl4PuuOp FbBbkEJddHX3v2NVhKuidIkxcwXMp2TitDcyo61FDf2nAE3ASyPfcrT49ktTE+6EqmTe Y8cWmOU/IaQTie6SdB+rRBsbBMKS3SR5BDdcJi+N/rAWKJDOfU8SIYXs1hi/kd9CML7o MkbvdI7HaspEZs2bFoTRHchZIhu7uTJ4thR5eqa9D/f3zeZGlvRZLT/AvWwDiI/dO5Pk /kUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=N1kmrdQXG5vssjwCd67eTK4dWVDhQf2oRjU5ZbEWya4=; b=HMPUGfUmpgpVY6tMWqax/5YmmC3120ZURuR1Nu/+AybnPFcYPAm4E0O96+j+MAwAtS 3KkjFPeRfbYxe/75u3f4idytUEkpdB/5d/goN6xBIKZPW0hYQG/Dfhz1wrtyzXUBK0qv kWlCVMPY4/YQJKvV13Ts9mX7I9wQzL1Z/3qvtfRsdS7jP12SX1aCoBUe8kmT09AcaQOx jdODTdD9PCVlRoTJVlF8uk4A5sLv5tUbIQuwIbqD6NOSr6Z6LTrrZ3YP9xH28zOrS8An aNBqB0vq22alQLAIXRD/oMf+lwdCPgsOxg8wCDY44LRUVE1RuYCzM4zFXXmNnFWu39tx MpSA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d0L2NJu3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x50si2671791eda.155.2019.11.07.13.04.42; Thu, 07 Nov 2019 13:05:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d0L2NJu3; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726504AbfKGVA0 (ORCPT + 99 others); Thu, 7 Nov 2019 16:00:26 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:36457 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbfKGVA0 (ORCPT ); Thu, 7 Nov 2019 16:00:26 -0500 Received: by mail-io1-f67.google.com with SMTP id s3so3898536ioe.3 for ; Thu, 07 Nov 2019 13:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N1kmrdQXG5vssjwCd67eTK4dWVDhQf2oRjU5ZbEWya4=; b=d0L2NJu3gPoGrUeZiF8fvX69O8lD9EF9IDygPpfopNtglqZUGyJ1oom8QPjw8flAg+ XNVxK87p3Ti5+74nIUhY6IhruUapE1XKdqkQSOKaaBtGVqyjSDe/N92cA/6jiDgXW3YO +FuexexIJ/EWzlCC+k7pZE1sRwB+OQiF9TROWcZ9L4Jn6WvMTV/2IhCjcY+o/RupSMPT wH9G0EvaN7+okWhtfkXWip0lXr37mvB04AceBMaer98vIjrDDD4vzgVGiiZJyghqdfTL lxKaeAKWMZVexLbr6yrOQcrEYXGyxk0GrBWtWhnJYU5xIFf5g6DxOdsI68uT9zGXevaT FdHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N1kmrdQXG5vssjwCd67eTK4dWVDhQf2oRjU5ZbEWya4=; b=b40wxm7bFipRDA3dBPPa978/HJAlQis5avAC62Mz/4JZ4ALO6fySGzfndTamzRHkp+ ceRS2MXzCYeyM8RaOqbe2p9W+tGWZDNN6YmlwerHQskT43HmD9sne2itR2BM8uyVhLHd EYwfZGqiEa5aB/eWyGjMfeZvsggc4/zSOFH+zFaDb9pYuVeXJ1/4l2Wlf2XODlJTLEt3 Yt/IKM2PFVGWrWGXD/yRilKKduc2eUPVvZb5qEW+NPKpfnGC/aR2jGWK6u8jhYh0+pl1 oBlfux7+Haucc9EYHg4TlCk2/f6B09B9g3PXzEZN+ksqsa87jWfPEkOxd9oMsu+Q9Nq3 LlHw== X-Gm-Message-State: APjAAAUggnUR9omYBwuyUugdwI679twnJfKsUmQXkAL3L9CiSKjUXfqR MhPxuHpR6AtlrYSf+TVOb4hpRANBJohndU29lnWMzlVwzg== X-Received: by 2002:a5d:8450:: with SMTP id w16mr5459728ior.11.1573160425402; Thu, 07 Nov 2019 13:00:25 -0800 (PST) MIME-Version: 1.0 References: <20191106193459.581614484@linutronix.de> <20191106202806.241007755@linutronix.de> In-Reply-To: From: Brian Gerst Date: Thu, 7 Nov 2019 16:00:13 -0500 Message-ID: Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further To: Linus Torvalds Cc: Thomas Gleixner , LKML , "the arch/x86 maintainers" , Stephen Hemminger , Willy Tarreau , Juergen Gross , Sean Christopherson , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 7, 2019 at 2:54 PM Linus Torvalds wrote: > > On Thu, Nov 7, 2019 at 11:24 AM Brian Gerst wrote: > > > > Here is a different idea: We already map the TSS virtually in > > cpu_entry_area. Why not page-align the IO bitmap and remap it to the > > task's bitmap on task switch? That would avoid all copying on task > > switch. > > We map the tss _once_, statically, percpu, without ever changing it, > and then we just (potentially) change a couple of fields in it on > process switch. > > Your idea isn't horrible, but it would involve a TLB flush for the > page when the io bitmap changes. Which is almost certainly more > expensive than just copying the bitmap intelligently. > > Particularly since I do think that the copy can basically be done > effectively never, assuming there really aren't multiple concurrent > users of ioperm() (and iopl). There wouldn't have to be a flush on every task switch. If we make it so that tasks that don't use a bitmap just unmap the pages in the cpu_entry_area and set tss.io_bitmap_base to outside the segment limit, we would only have to flush when switching from a task using the bitmap (because the next task uses a different bitmap or we are unmapping it). If the previous task doesn't have a bitmap the pages in cpu_entry_area were unmapped and can't be in the TLB, so no flush is needed. Going a step further, we could track which task is mapped to the current cpu like proposed above, and only flush when a different task needs the IO bitmap, or when the bitmap is being freed on task exit. -- Brian Gerst