From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Cc: "Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
patches@linaro.org,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
"Greg Bellows" <greg.bellows@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <rth@twiddle.net>
Subject: [Qemu-devel] [RFC 0/5] Memory transaction attributes API
Date: Mon, 16 Mar 2015 17:20:17 +0000 [thread overview]
Message-ID: <1426526422-28338-1-git-send-email-peter.maydell@linaro.org> (raw)
This is an RFC patchset aimed at getting comment on
some memory API changes to support "transaction attributes",
ie sideband information that goes along with a memory read
or write access to define things like ARM secure/nonsecure,
CPU/transaction master ID, privileged/nonprivileged.
(See also previous discussion:
https://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg01026.html )
Patch 1 is the API changes themselves:
1) new read_with_attrs and write_with_attrs fields in the
MemoryRegionOps struct; the old read/write still exist
for backwards compatibility, but devices that care about
attributes can register with these function pointers instead
2) the functions return a success/failure status, so a device
can actually fail bad transactions rather than merely
returning bogus data. (This isn't wired up in this patchset
but I include it to avoid revving the memory API twice.)
Patches 2, 3 and 4 then plumb the memory attribute parameters
through the various functions, working upwards to being able
to put them in the iotlb. Patch 5 implements the target-arm
changes to provide a secure/nonsecure tx attribute based on
the page table walk, as a demonstration.
There are obviously more APIs within QEMU for memory access
functions which need to change to either always take a tx
attribute, or to have extra with-tx-attribute versions of the
functions. For the moment things are stubbed out with passing
in "no attributes specified" values.
I've modelled the transaction attributes as a (typedefed)
uint64_t, whose bits will be defined as we find requirements
for them (the meaning will not be per-architecture). When
we originally discussed this on-list, Edgar suggested making
the attributes be a (pointer to a) struct; however I found
the ownership/copying semantics on this too awkward, because
the access path needs to take attributes set up in the TLB
and then modify them according to details of the access
actually being made before passing them to the device, so
took the simpler implementation route.
I intend to continue working on this (filling in the gaps,
etc), but wanted to send this series out early for comment
on the memory API changes in particular.
thanks
-- PMM
Peter Maydell (5):
memory: Define API for MemoryRegionOps to take attrs and return status
memory: Add MemTxAttrs argument to io_mem_read and io_mem_write
Make CPU iotlb a structure rather than a plain hwaddr
Add MemTxAttrs to the IOTLB
target-arm: Honour NS bits in page tables
cputlb.c | 22 +++++++---
exec.c | 29 +++++++-------
hw/s390x/s390-pci-inst.c | 7 ++--
hw/vfio/pci.c | 4 +-
include/exec/cpu-defs.h | 15 ++++++-
include/exec/exec-all.h | 8 +++-
include/exec/memattrs.h | 37 +++++++++++++++++
include/exec/memory.h | 22 ++++++++++
memory.c | 102 +++++++++++++++++++++++++++++++++++++----------
softmmu_template.h | 36 +++++++++--------
target-arm/helper.c | 83 ++++++++++++++++++++++++++++++++------
11 files changed, 288 insertions(+), 77 deletions(-)
create mode 100644 include/exec/memattrs.h
--
1.9.1
next reply other threads:[~2015-03-16 17:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 17:20 Peter Maydell [this message]
2015-03-16 17:20 ` [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status Peter Maydell
2015-03-27 10:58 ` Peter Maydell
2015-03-27 12:02 ` Edgar E. Iglesias
2015-03-27 12:10 ` Paolo Bonzini
2015-03-27 12:32 ` Edgar E. Iglesias
2015-03-27 13:16 ` Paolo Bonzini
2015-03-27 13:35 ` Edgar E. Iglesias
2015-03-27 12:10 ` Peter Maydell
2015-03-16 17:20 ` [Qemu-devel] [RFC 2/5] memory: Add MemTxAttrs argument to io_mem_read and io_mem_write Peter Maydell
2015-03-16 17:20 ` [Qemu-devel] [RFC 3/5] Make CPU iotlb a structure rather than a plain hwaddr Peter Maydell
2015-03-16 17:20 ` [Qemu-devel] [RFC 4/5] Add MemTxAttrs to the IOTLB Peter Maydell
2015-03-16 17:20 ` [Qemu-devel] [RFC 5/5] target-arm: Honour NS bits in page tables Peter Maydell
2015-03-18 8:38 ` [Qemu-devel] [RFC 0/5] Memory transaction attributes API Edgar E. Iglesias
2015-03-18 10:23 ` 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=1426526422-28338-1-git-send-email-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=edgar.iglesias@gmail.com \
--cc=greg.bellows@linaro.org \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).