All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Tom Hanson <thomas.hanson@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Grant Likely <grant.likely@hpe.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses
Date: Fri, 30 Sep 2016 16:24:38 -0700	[thread overview]
Message-ID: <CAFEAcA_dqm6VgUvoTez8Mcu_Tcv9V+Tng46kw7gSsR+ohfW6QA@mail.gmail.com> (raw)
In-Reply-To: <57EEEB2D.7010100@linaro.org>

On 30 September 2016 at 15:46, Tom Hanson <thomas.hanson@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.

>>> 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.

Yes, I still think this. What does it have to do with adding
"SVC", "HVC", etc comments to the switch cases? Those have
nothing to do with tagged addresses or 56 bit VAs, and should
not be in this patch (though I don't object to them inherently).

thanks
-- PMM

  reply	other threads:[~2016-09-30 23:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 17:34 [Qemu-devel] [PATCH 0/3] tareget-arm: Handle tagged addresses when loading PC Thomas Hanson
2016-09-16 17:34 ` [Qemu-devel] [PATCH 1/3] target-arm: Infrastucture changes to enable handling of tagged address loading into PC Thomas Hanson
2016-09-30  0:58   ` Peter Maydell
2016-09-16 17:34 ` [Qemu-devel] [PATCH 2/3] target-arm: Code changes to implement overwrite of tag field on PC load Thomas Hanson
2016-09-30  1:24   ` Peter Maydell
2016-10-05 21:53     ` Tom Hanson
2016-10-05 22:01       ` Peter Maydell
2016-10-11 15:51         ` Thomas Hanson
2016-10-11 16:02           ` Richard Henderson
2016-10-11 16:12           ` Peter Maydell
2016-10-12 19:52             ` Tom Hanson
2016-09-16 17:34 ` [Qemu-devel] [PATCH 3/3] target-arm: Comments to mark location of pending work for 56 bit addresses Thomas Hanson
2016-09-30  1:27   ` Peter Maydell
2016-09-30 22:46     ` Tom Hanson
2016-09-30 23:24       ` Peter Maydell [this message]
2016-10-03 17:01         ` Tom Hanson
2016-10-03 18:26         ` Tom Hanson
2016-09-30  1:37 ` [Qemu-devel] [PATCH 0/3] tareget-arm: Handle tagged addresses when loading PC Peter Maydell
2016-09-30 21:48   ` Tom Hanson
2016-09-30 22:06     ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFEAcA_dqm6VgUvoTez8Mcu_Tcv9V+Tng46kw7gSsR+ohfW6QA@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=grant.likely@hpe.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thomas.hanson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.