From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br7ww-0001sC-UL for qemu-devel@nongnu.org; Mon, 03 Oct 2016 14:26:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1br7ws-0005Cd-Ls for qemu-devel@nongnu.org; Mon, 03 Oct 2016 14:26:49 -0400 Received: from mail-pa0-x234.google.com ([2607:f8b0:400e:c03::234]:35542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br7ws-0005C8-Cp for qemu-devel@nongnu.org; Mon, 03 Oct 2016 14:26:46 -0400 Received: by mail-pa0-x234.google.com with SMTP id ik13so10793886pac.2 for ; Mon, 03 Oct 2016 11:26:46 -0700 (PDT) References: <1474047287-145701-1-git-send-email-thomas.hanson@linaro.org> <1474047287-145701-4-git-send-email-thomas.hanson@linaro.org> <57EEEB2D.7010100@linaro.org> From: Tom Hanson Message-ID: <57F2A2C3.2050106@linaro.org> Date: Mon, 3 Oct 2016 12:26:11 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Grant Likely On 09/30/2016 05:24 PM, Peter Maydell wrote: > On 30 September 2016 at 15:46, Tom Hanson wrote: >> On 09/29/2016 07:27 PM, Peter Maydell wrote: >> ... >>>> This work was not done at this time since the changes could not be tested >>>> with current CPU models. Comments have been added to flag the locations >>>> where this will need to be fixed once a model is available. >>> >>> This is *not* why we haven't done this work. We haven't done it >>> because the maximum virtual address size permitted by the >>> architecture is less than 56 bits, and so this is a "can't happen" >>> situation. >> >> But, in an earlier discussion which we had about the desire to use QEMU >> to test potential new ARM-based architectures with large address spaces >> I suggested that these changes be made now. You said that the changes >> shouldn't be made because: >> where there is no supported guest CPU that could use >> that code, the code shouldn't be there because it's untested >> and untestable >> Isn't that the same thing I said above? > > That's a general statement of principle about what I think we > should or shouldn't write code for in QEMU. In this particular case, > it's true, but the reason it's true isn't just that we don't > currently have any 56 bit-VA CPUs implemented, but because such > a CPU is not permitted by the architecture. That's a stronger > statement and I think it's worth making. > Per the current spec (and v2) that's true. But the intent was to enable testing of "new ARM-based architectures with large address spaces." Vendors and OEMs may have difficulty in determining whether to ask for / push for / support a future, larger address space in the absence of a platform which is capable of emulating the future architecture.