From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bq6aI-0007LD-Ku for qemu-devel@nongnu.org; Fri, 30 Sep 2016 18:47:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bq6aE-0008Lg-BM for qemu-devel@nongnu.org; Fri, 30 Sep 2016 18:47:13 -0400 Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]:34328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bq6aE-0008LT-6U for qemu-devel@nongnu.org; Fri, 30 Sep 2016 18:47:10 -0400 Received: by mail-oi0-x233.google.com with SMTP id n132so82021923oih.1 for ; Fri, 30 Sep 2016 15:47:10 -0700 (PDT) References: <1474047287-145701-1-git-send-email-thomas.hanson@linaro.org> <1474047287-145701-4-git-send-email-thomas.hanson@linaro.org> From: Tom Hanson Message-ID: <57EEEB2D.7010100@linaro.org> Date: Fri, 30 Sep 2016 16:46:05 -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/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? >> 3 comments added in same file to identify cases in a switch. > > This should be a separate patch, because it is unrelated to the > tagged address stuff. As part of that same conversation you suggested adding these comments rather than making the changes: If we can assert, or failing that have a comment in the place that would be modified anyway for 56 bit addresses then that ought to catch the future case I think.