qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

             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).