[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
- [Qemu-devel] [RFC 0/5] Memory transaction attributes API,
Peter Maydell <=
- [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Peter Maydell, 2015/03/16
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Peter Maydell, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Edgar E. Iglesias, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Paolo Bonzini, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Edgar E. Iglesias, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Paolo Bonzini, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Edgar E. Iglesias, 2015/03/27
- Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status, Peter Maydell, 2015/03/27
[Qemu-devel] [RFC 2/5] memory: Add MemTxAttrs argument to io_mem_read and io_mem_write, Peter Maydell, 2015/03/16
[Qemu-devel] [RFC 4/5] Add MemTxAttrs to the IOTLB, Peter Maydell, 2015/03/16