qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC 0/5] Memory transaction attributes API


From: Peter Maydell
Subject: [Qemu-devel] [RFC 0/5] Memory transaction attributes API
Date: Mon, 16 Mar 2015 17:20:17 +0000

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 via email to

[Prev in Thread] Current Thread [Next in Thread]