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;
Date:   Thu, 7 Nov 2019 08:37:20 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Stephen Hemminger <stephen@networkplumber.org>,
        Willy Tarreau <w@1wt.eu>, Juergen Gross <jgross@suse.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage
 further
Message-ID: <20191107073719.GD30739@gmail.com>
References: <20191106193459.581614484@linutronix.de>
 <20191106202806.241007755@linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191106202806.241007755@linutronix.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* Thomas Gleixner <tglx@linutronix.de> wrote:

> @@ -365,19 +365,19 @@ struct tss_struct {
>  	struct x86_hw_tss	x86_tss;
>  
>  	/*
> -	 * Store the dirty size of the last io bitmap offender. The next
> -	 * one will have to do the cleanup as the switch out to a non
> -	 * io bitmap user will just set x86_tss.io_bitmap_base to a value
> -	 * outside of the TSS limit. So for sane tasks there is no need
> -	 * to actually touch the io_bitmap at all.
> +	 * Store the dirty byte range of the last io bitmap offender. The
> +	 * next one will have to do the cleanup because the switch out to a
> +	 * non I/O bitmap user will just set x86_tss.io_bitmap_base to a
> +	 * value outside of the TSS limit to not penalize tasks which do
> +	 * not use the I/O bitmap at all.
>  	 */
> -	unsigned int		io_bitmap_prev_max;
> +	unsigned int		io_zerobits_start;
> +	unsigned int		io_zerobits_end;
>  
>  	/*
> -	 * The extra 1 is there because the CPU will access an
> -	 * additional byte beyond the end of the IO permission
> -	 * bitmap. The extra byte must be all 1 bits, and must
> -	 * be within the limit.
> +	 * The extra 1 is there because the CPU will access an additional
> +	 * byte beyond the end of the I/O permission bitmap. The extra byte
> +	 * must have all bits set and must be within the TSS limit.
>  	 */
>  	unsigned long		io_bitmap[IO_BITMAP_LONGS + 1];
>  } __aligned(PAGE_SIZE);

Note that on 32-bit kernels this blows up our CPU area calculations:

./include/linux/compiler.h:350:38: error: call to ‘__compiletime_assert_181’ declared with attribute error: BUILD_BUG_ON failed: CPU_ENTRY_AREA_PAGES * PAGE_SIZE < CPU_ENTRY_AREA_MAP_SIZE
./include/linux/compiler.h:331:4: note: in definition of macro ‘__compiletime_assert’
./include/linux/compiler.h:350:2: note: in expansion of macro ‘_compiletime_assert’
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
arch/x86/mm/cpu_entry_area.c:181:2: note: in expansion of macro ‘BUILD_BUG_ON’
make[2]: *** [scripts/Makefile.build:265: arch/x86/mm/cpu_entry_area.o] Error 1

Thanks,

	Ingo