From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Peter Maydell" <peter.maydell@linaro.org>
Cc: "Joel Stanley" <joel@jms.id.au>,
"Cameron Esfahani" <dirty@apple.com>,
"Cameron Esfahani via" <qemu-devel@nongnu.org>,
"Cédric Le Goater" <clg@kaod.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH v1] nrf51: Fix last GPIO CNF address
Date: Fri, 10 Apr 2020 23:05:51 +0930 [thread overview]
Message-ID: <3a0ef208-aa2e-400f-b5c8-d9920bee0b5a@www.fastmail.com> (raw)
In-Reply-To: <CAFEAcA-TrDeO2xKWYbxLfAuavGQkzsH-etQogv9LVQvF+j=U4w@mail.gmail.com>
On Fri, 10 Apr 2020, at 21:56, Peter Maydell wrote:
> On Fri, 10 Apr 2020 at 04:42, Andrew Jeffery <andrew@aj.id.au> wrote:
> > IIRC Phil wanted to enable sub-word accesses to the sample value
> > registers but I didn't want to spread logic dealing with different access
> > widths through the model. We already had a mechanism to describe the
> > model's supported access sizes (as opposed to the valid access sizes
> > allowed by hardware) in the `impl` member of the MemoryRegionOps, so
> > I was trying to use that, but it didn't work as I needed.
> >
> > The accesses generated at the point of the guest MMIO need to be
> > expanded to the access width supported by the model and then the
> > resulting data trimmed again upon returning the data (in the case of a
> > read) via the MMIO operation.
> >
> > So the intent was less about unaligned accesses than enabling models
> > implementations that only have to handle certain-sized access widths.
> > It happens to help the unaligned access case as well.
>
> Yeah, we definitely could do with improving things here, it is annoying
> to have to write code for handling some of the oddball cases when you
> have just one register that allows byte accesses or whatever.
> The thing I have in the back of my mind as a concern is that we have
> had several "is this a buffer overrun" questions where the answer has
> been "it can't be, because the core code doesn't allow a call to the
> read/write function for a 4 byte access where the address is not 4-aligned,
> so my_byte_array[addr] is always in-bounds".
> So if we change the core code we need to make sure we don't
> inadvertently remove a restriction that was protecting us from a guest
> escape...
Oh for sure. The patch was very RFC, as mentioned I just sent it to check
whether I was on the right track or off in the weeds, and from there it has
hung around in Cedric's tree without much progress.
Feels like the time is right to sort the problem out properly, which might
mean starting from scratch to make sure we don't miss any of the details.
Andrew
next prev parent reply other threads:[~2020-04-10 13:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 22:55 [PATCH v1] nrf51: Fix last GPIO CNF address Cameron Esfahani via
2020-04-07 6:49 ` Cédric Le Goater
2020-04-07 8:40 ` Peter Maydell
2020-04-07 8:45 ` Joel Stanley
2020-04-07 8:50 ` Peter Maydell
2020-04-10 3:42 ` Andrew Jeffery
2020-04-10 12:26 ` Peter Maydell
2020-04-10 13:35 ` Andrew Jeffery [this message]
2020-04-07 8:44 ` Philippe Mathieu-Daudé
2020-04-07 10:09 ` Cameron Esfahani via
2020-04-14 8:56 ` Joel Stanley
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=3a0ef208-aa2e-400f-b5c8-d9920bee0b5a@www.fastmail.com \
--to=andrew@aj.id.au \
--cc=clg@kaod.org \
--cc=dirty@apple.com \
--cc=joel@jms.id.au \
--cc=kraxel@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).