On 09/30/2016 05:24 PM, Peter Maydell wrote: > On 30 September 2016 at 15:46, Tom Hanson <thomas.han...@linaro.org> 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.
