[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pe
From: |
Tom Hanson |
Subject: |
Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses |
Date: |
Mon, 3 Oct 2016 12:26:11 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
On 09/30/2016 05:24 PM, Peter Maydell wrote:
> On 30 September 2016 at 15:46, Tom Hanson <address@hidden> 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.