From: Laszlo Ersek <lersek@redhat.com>
To: "Gabriel L. Somlo" <somlo@cmu.edu>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, jordan.l.justen@intel.com,
armbru@redhat.com, kraxel@redhat.com, pbonzini@redhat.com,
markmb@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 5/6] fw_cfg: add generic non-DMA read method
Date: Thu, 5 Nov 2015 17:18:44 +0100 [thread overview]
Message-ID: <563B8164.9040609@redhat.com> (raw)
In-Reply-To: <1446733972-1602-6-git-send-email-somlo@cmu.edu>
On 11/05/15 15:32, Gabriel L. Somlo wrote:
> Introduce fw_cfg_data_read(), a generic read method which works
> on all access widths (1 through 8 bytes, inclusive), and can be
> used during both IOPort and MMIO read accesses.
>
> To maintain legibility, only fw_cfg_data_mem_read() (the MMIO
> data read method) is replaced by this patch. The new method
> essentially unwinds the fw_cfg_data_mem_read() + fw_cfg_read()
> combo, but without unnecessarily repeating all the validity
> checks performed by the latter on each byte being read.
>
> This patch also modifies the trace_fw_cfg_read prototype to
> accept a 64-bit value argument, allowing it to work properly
> with the new read method, but also remain backward compatible
> with existing call sites.
>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Marc Marí <markmb@redhat.com>
> Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> ---
>
> I think in this case I'll stick with a single assert for the
> whole bounds check. In the long run, "easy to read" might be
> just a bit more helpful than "in the VERY unlikely event of
> actually triggering this, it will also tell us which side of
> the interval we fell out on"...
>
> Thanks again for all the advice and feedback!
> --Gabriel
>
> hw/nvram/fw_cfg.c | 45 +++++++++++++++++++++++++++++++--------------
> trace-events | 2 +-
> 2 files changed, 32 insertions(+), 15 deletions(-)
>
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 046fa74..8f566f6 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -274,6 +274,36 @@ static int fw_cfg_select(FWCfgState *s, uint16_t key)
> return ret;
> }
>
> +static uint64_t fw_cfg_data_read(void *opaque, hwaddr addr, unsigned size)
> +{
> + FWCfgState *s = opaque;
> + int arch = !!(s->cur_entry & FW_CFG_ARCH_LOCAL);
> + FWCfgEntry *e = (s->cur_entry == FW_CFG_INVALID) ? NULL :
> + &s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
> + uint64_t value = 0;
> +
> + assert(size > 0 && size <= sizeof(value));
> + if (s->cur_entry != FW_CFG_INVALID && e->data && s->cur_offset < e->len) {
> + /* The least significant 'size' bytes of the return value are
> + * expected to contain a string preserving portion of the item
> + * data, padded with zeros on the right in case we run out early.
> + * In technical terms, we're composing the host-endian representation
> + * of the big endian interpretation of the fw_cfg string.
> + */
> + do {
> + value = (value << 8) | e->data[s->cur_offset++];
> + } while (--size && s->cur_offset < e->len);
> + /* If size is still not zero, we *did* run out early, so continue
> + * left-shifting, to add the appropriate number of padding zeros
> + * on the right.
> + */
> + value <<= 8 * size;
> + }
> +
> + trace_fw_cfg_read(s, value);
> + return value;
> +}
> +
> static uint8_t fw_cfg_read(FWCfgState *s)
> {
> int arch = !!(s->cur_entry & FW_CFG_ARCH_LOCAL);
> @@ -291,19 +321,6 @@ static uint8_t fw_cfg_read(FWCfgState *s)
> return ret;
> }
>
> -static uint64_t fw_cfg_data_mem_read(void *opaque, hwaddr addr,
> - unsigned size)
> -{
> - FWCfgState *s = opaque;
> - uint64_t value = 0;
> - unsigned i;
> -
> - for (i = 0; i < size; ++i) {
> - value = (value << 8) | fw_cfg_read(s);
> - }
> - return value;
> -}
> -
> static void fw_cfg_data_mem_write(void *opaque, hwaddr addr,
> uint64_t value, unsigned size)
> {
> @@ -485,7 +502,7 @@ static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
> };
>
> static const MemoryRegionOps fw_cfg_data_mem_ops = {
> - .read = fw_cfg_data_mem_read,
> + .read = fw_cfg_data_read,
> .write = fw_cfg_data_mem_write,
> .endianness = DEVICE_BIG_ENDIAN,
> .valid = {
> diff --git a/trace-events b/trace-events
> index 17fbddf..f2f2ce4 100644
> --- a/trace-events
> +++ b/trace-events
> @@ -196,7 +196,7 @@ ecc_diag_mem_readb(uint64_t addr, uint32_t ret) "Read diagnostic %"PRId64"= %02x
>
> # hw/nvram/fw_cfg.c
> fw_cfg_select(void *s, uint16_t key, int ret) "%p key %d = %d"
> -fw_cfg_read(void *s, uint8_t ret) "%p = %d"
> +fw_cfg_read(void *s, uint64_t ret) "%p = %"PRIx64
> fw_cfg_add_file(void *s, int index, char *name, size_t len) "%p #%d: %s (%zd bytes)"
>
> # hw/block/hd-geometry.c
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
next prev parent reply other threads:[~2015-11-05 16:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 14:32 [Qemu-devel] [PATCH v5 0/6] fw_cfg: spec update, misc. cleanup, optimize read Gabriel L. Somlo
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 1/6] fw_cfg: move internal function call docs to header file Gabriel L. Somlo
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 2/6] fw_cfg: amend callback behavior spec to once per select Gabriel L. Somlo
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 3/6] fw_cfg: remove offset argument from callback prototype Gabriel L. Somlo
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 4/6] fw_cfg: avoid calculating invalid current entry pointer Gabriel L. Somlo
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 5/6] fw_cfg: add generic non-DMA read method Gabriel L. Somlo
2015-11-05 16:18 ` Laszlo Ersek [this message]
2015-11-05 14:32 ` [Qemu-devel] [PATCH v5 6/6] fw_cfg: replace ioport data read with generic method Gabriel L. Somlo
2015-11-05 16:11 ` Laszlo Ersek
2015-11-23 14:18 ` [Qemu-devel] [PATCH v5 0/6] fw_cfg: spec update, misc. cleanup, optimize read Gabriel L. Somlo
2015-11-24 7:21 ` Gerd Hoffmann
2015-11-24 12:29 ` Gabriel L. Somlo
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=563B8164.9040609@redhat.com \
--to=lersek@redhat.com \
--cc=armbru@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=kraxel@redhat.com \
--cc=markmb@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
/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.