From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752796AbdJTTRB (ORCPT ); Fri, 20 Oct 2017 15:17:01 -0400 Received: from mga11.intel.com ([192.55.52.93]:28751 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590AbdJTTQ7 (ORCPT ); Fri, 20 Oct 2017 15:16:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,408,1503385200"; d="scan'208";a="1233292718" Date: Fri, 20 Oct 2017 12:16:06 -0700 From: Ricardo Neri To: Borislav Petkov Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Brian Gerst , Chris Metcalf , Dave Hansen , Paolo Bonzini , Masami Hiramatsu , Huang Rui , Jiri Slaby , Jonathan Corbet , "Michael S. Tsirkin" , Paul Gortmaker , Vlastimil Babka , Chen Yucong , "Ravi V. Shankar" , Shuah Khan , linux-kernel@vger.kernel.org, x86@kernel.org, ricardo.neri@intel.com, Adam Buchbinder , Colin Ian King , Lorenzo Stoakes , Qiaowei Ren , Arnaldo Carvalho de Melo , Adrian Hunter , Kees Cook , Thomas Garnier , Dmitry Vyukov Subject: Re: [PATCH v9 19/29] x86/insn-eval: Add support to resolve 32-bit address encodings Message-ID: <20171020191606.GA21743@voyager> References: <1507089272-32733-1-git-send-email-ricardo.neri-calderon@linux.intel.com> <1507089272-32733-20-git-send-email-ricardo.neri-calderon@linux.intel.com> <20171020171229.pofottubbjnwgmws@pd.tnic> <20171020182448.GE12298@voyager> <20171020183825.rqg462eluhr2f2ae@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171020183825.rqg462eluhr2f2ae@pd.tnic> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 20, 2017 at 08:38:25PM +0200, Borislav Petkov wrote: > On Fri, Oct 20, 2017 at 11:24:48AM -0700, Ricardo Neri wrote: > > I will create these helper functions. This change and your suggestion in > > patch 18 will impact other patches in the series (e.g., the function > > get_addr_ref_16() in patch 22). Would it make sense to submit a v10 and > > resume review there? > > > > Also, do you think I am still on-time to make it to v4.15? > > Well, I've been thinking about it: handling huge patchsets is always > very cumbersome, time-consuming and error prone. So perhaps it would be > easier - maybe - I'm not saying it will definitely but only maybe - if > you would split the patchset into, say, two, pieces, or halves, if you > will. > > And I think the first piece is more or less reviewed and if tip guys > don't find any booboos, it could go in now. Which would free you to deal > with the other half later. Since MPX uses this emulation code and only cares about 64-bit addresses (given the initial implemention from which I based my code), patches 1-18 need to be pulled together. Perhaps I can send the v10 of patches 1-18 (or a v1 since is a new series?). Patches 19-29 would constitute a series of improved emulation plus UMIP code. Does it make sense? Thanks and BR, Ricardo > --