Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3204624ybx; Fri, 8 Nov 2019 15:49:22 -0800 (PST) X-Google-Smtp-Source: APXvYqzGQAysU3CbwPC8upWJW+IoovzloS1p4hw65lGsoDPomIHL91ZxVOzcBYQr+7JBOFiFz0QI X-Received: by 2002:a17:906:1d01:: with SMTP id n1mr11006261ejh.95.1573256962410; Fri, 08 Nov 2019 15:49:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573256962; cv=none; d=google.com; s=arc-20160816; b=gp1Sd5S6osAkM6PQh/3K0gROBO9KsYWcwHyLZEGIMzFICDPLNo/GclZ6vKqirHDWx2 pLxzrfDBc5Gq/93dU/GsGkxuGLsOMIvI3iQeH5rV9bquHwV+D00ZPWaXC3ZGMzn6wIAh JGXrph2YruuYZZwc6ZUqTua6kQAew54l9nErHYF4HuZzKtN291906VkEtIAo0sYwHz1z 7uqQx1SrJad6M4/z/UwKsyeS+lRPxmqtq9gieMr+kRqLQWfa06e+Qfs6xq5XvTWpi58l vuT42tcyk5NDPoqDvisXWwxWE97xThqZv81pUswyIiYg4Sawy7yMOWMctUDJXShhrc2p 5zgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=+MrEkiFosEbYtlR6GrZ/NM2SJAens5/gJgBav9/KAqk=; b=GhIVhwy4qdXDp+xP5xj0J/txziYQmgViis1mgMxNyMhcJkrliprE8B0X09Xiby/t4p 6PppdgYOnr4wKwVRGMczpV1JPTj5RWfmLiThn4jnqy5YSNliz8YmI0k4yNTtNWKOv8j9 hojp2UwHvBPHSFW2ivl6JYxFas4WliP+n0QNF8ub0hGJ4oc0xTFTfHYPXOLehPkgkg5u 3slM2K9m26HNvHjCSlbM7J8MIwZ9h/AKapov04wCabxPn6CDWEhrQF57sD4EjTXH9LUN SO0QZcNU9MuaPrK2SZfRu6pNj4y9X2/PiqMobAzC2EXqktruC+QoH2NlaTk+w63CbpeK 25kQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x37si6119264edd.228.2019.11.08.15.48.57; Fri, 08 Nov 2019 15:49:22 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730165AbfKHXpz (ORCPT + 99 others); Fri, 8 Nov 2019 18:45:55 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:52813 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726640AbfKHXpy (ORCPT ); Fri, 8 Nov 2019 18:45:54 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iTDwq-0005lm-Bj; Sat, 09 Nov 2019 00:45:49 +0100 Date: Sat, 9 Nov 2019 00:45:47 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: Peter Zijlstra , LKML , x86@kernel.org, Stephen Hemminger , Willy Tarreau , Juergen Gross , Sean Christopherson , Linus Torvalds , "H. Peter Anvin" Subject: Re: [patch 4/9] x86/io: Speedup schedule out of I/O bitmap user In-Reply-To: Message-ID: References: <20191106193459.581614484@linutronix.de> <20191106202806.133597409@linutronix.de> <20191107091231.GA4131@hirez.programming.kicks-ass.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 8 Nov 2019, Andy Lutomirski wrote: > On 11/7/19 6:08 AM, Thomas Gleixner wrote: > > On Thu, 7 Nov 2019, Thomas Gleixner wrote: > >> Just that I can't add the storage to tss_struct due to the VMX insanity of > >> setting TSS limit hard to 0x67 on vmexit instead of restoring the host > >> value. > > > > Well, I can. The build bugon in vmx.c is just bogus. > > SDM vol 3 27.5.2 says the BUILD_BUG_ON is right. Or am I > misunderstanding you? > > I'm reasonably confident that the TSS limit is indeed 0x67 after VM > exit, and I wrote the existing code that tries to optimize this to avoid > LTR when not needed. The BUILD_BUG_ON(IO_BITMAP_OFFSET - 1 == 0x67) in the VMX code is bogus in two aspects: 1) This wants to be in generic x86 code 2) The IO_BITMAP_OFFSET is not the right thing to check because it makes asssumptions about the layout of tss_struct. Nothing requires that the I/O bitmap is placed right after x86_tss, which is the hardware mandated tss structure. It pointlessly makes restrictions on the struct tss_struct layout. The proper thing to check is: - Offset of x86_tss in tss_struct is 0 - Size of x86_tss == 0x68 We already have the page alignment sanity check off TSS in cpu_entry_area.c. That's where this should have gone into in the first place. Thanks, tglx