From: "Gabriel L. Somlo" <somlo@cmu.edu>
To: 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, lersek@redhat.com
Subject: [Qemu-devel] [PATCH v5 5/6] fw_cfg: add generic non-DMA read method
Date: Thu, 5 Nov 2015 09:32:51 -0500 [thread overview]
Message-ID: <1446733972-1602-6-git-send-email-somlo@cmu.edu> (raw)
In-Reply-To: <1446733972-1602-1-git-send-email-somlo@cmu.edu>
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
--
2.4.3
next prev parent reply other threads:[~2015-11-05 14:33 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 ` Gabriel L. Somlo [this message]
2015-11-05 16:18 ` [Qemu-devel] [PATCH v5 5/6] fw_cfg: add generic non-DMA read method Laszlo Ersek
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=1446733972-1602-6-git-send-email-somlo@cmu.edu \
--to=somlo@cmu.edu \
--cc=armbru@redhat.com \
--cc=jordan.l.justen@intel.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=markmb@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--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).