From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVNx7-0005hY-8L for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:28:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVNx4-0003tV-Dy for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:28:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVNx4-0003sZ-66 for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:28:18 -0400 Date: Tue, 10 Mar 2015 18:28:11 +0100 From: Andrew Jones Message-ID: <20150310172810.GH6320@hawk.usersys.redhat.com> References: <1423753507-30542-1-git-send-email-drjones@redhat.com> <1423753507-30542-5-git-send-email-drjones@redhat.com> <20150310164759.GC6320@hawk.usersys.redhat.com> <20150310170212.GF6320@hawk.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 4/5] target-arm: get_phys_addr_lpae: more xn control List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers On Tue, Mar 10, 2015 at 05:14:21PM +0000, Peter Maydell wrote: > On 10 March 2015 at 17:02, Andrew Jones wrote: > > On Tue, Mar 10, 2015 at 04:55:53PM +0000, Peter Maydell wrote: > >> On 10 March 2015 at 16:48, Andrew Jones wrote: > >> > On Tue, Mar 10, 2015 at 03:56:11PM +0000, Peter Maydell wrote: > >> > >> >> For instance, you're missing a shift here on the ap bits, because > >> >> get_rw_prot needs AP[2:0] and 'ap' here is AP[2:1]. > >> > > >> > Don't need the shift because get_rw_prot supports the 2-bit format. > >> > >> No it doesn't... > > > > Yes it does :-) That's the support patch 2/5 adds. > > No, because patch 2 doesn't do anything in the callers to > make them pass only bits [2:1]. So after patch 2 get_rw_prot > still requires bits [2:0]. Except it's broken, because the > function itself assumes it gets bits [2:1]. You've lost me. Patch 2 adds support for 2-bit ap, but doesn't remove support for 3-bit. There are not callers expecting it to support the simple model as 2 or 3 bits at that time, except v6, but that was broken already, and we fix it in patch 5 (and we add the ap shift there too). IOW, how can preparing a function for new callers, while still supporting the old callers, be 'broken'? > > Having thought a bit more about it, I think we should > just have two totally separate functions for the old > style and simplified permission checks, because we can > always call the correct one (always old for v5, either > one for v6 since we already have the SCTLR.AFE check, > and the simplified one for the lpae code path). I like that. Thanks, drew