All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Kumar Gala <kumar.gala@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH for-6.0 0/2] arm: Make M-profile VTOR loads on reset handle memory aliasing
Date: Sat, 13 Mar 2021 19:41:13 +0000	[thread overview]
Message-ID: <CAFEAcA88EPzz2kh3gwL99nv=JxYcDQdBJxCDzOO5FfZ1NkQT9Q@mail.gmail.com> (raw)
In-Reply-To: <657618fc-9e62-6c24-c65d-ccc7375c7fcc@linaro.org>

On Sat, 13 Mar 2021 at 19:05, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 3/12/21 12:59 PM, Peter Maydell wrote:
> > On Fri, 12 Mar 2021 at 17:29, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> This series handles the possibility of aliasing by iterating through
> >> the whole FlatView of the CPU's address space checking for other
> >> mappings of the MemoryRegion corresponding to the location of the
> >> vector table.  If we find any aliases we use rom_ptr() to see if the
> >> ROM blob loader has any data there.
> >
> > The other possible place we could put this code would be
> > to put it into rom_ptr() itself. You'd have to change the
> > callsites to pass an AddressSpace to rom_ptr(), but really
> > we ought to do that anyway, because a Rom has an AddressSpace
> > that we should be checking as well as the address.
>
> I like this as the solution.

I realized that checking against the Rom's AddressSpace
is likely to be a bad plan, though -- in some cases the AS is
used to allow the loader to say "load this image to AS
such-and-such", and we don't want to fail to find the ROM
blob because the rom_ptr() code is reading it from a different
AS that is an alternate view onto the same actual MemoryRegions
(eg Secure vs NonSecure and the RAM is in the same place.)

thanks
-- PMM


      reply	other threads:[~2021-03-13 19:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 17:29 [PATCH for-6.0 0/2] arm: Make M-profile VTOR loads on reset handle memory aliasing Peter Maydell
2021-03-12 17:29 ` [PATCH for-6.0 1/2] memory: Add offset_in_region to flatview_cb arguments Peter Maydell
2021-03-12 20:09   ` Philippe Mathieu-Daudé
2021-03-12 17:29 ` [PATCH for-6.0 2/2] target/arm: Make M-profile VTOR loads on reset handle memory aliasing Peter Maydell
2021-03-12 20:17   ` Philippe Mathieu-Daudé
2021-03-13 19:03     ` Richard Henderson
2021-03-18 17:14     ` Peter Maydell
2021-03-12 18:59 ` [PATCH for-6.0 0/2] arm: " Peter Maydell
2021-03-13 19:05   ` Richard Henderson
2021-03-13 19:41     ` Peter Maydell [this message]

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='CAFEAcA88EPzz2kh3gwL99nv=JxYcDQdBJxCDzOO5FfZ1NkQT9Q@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=kumar.gala@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@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.