qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
	patches@linaro.org, qemu-devel@nongnu.org,
	"Greg Bellows" <greg.bellows@linaro.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC 0/5] Memory transaction attributes API
Date: Wed, 18 Mar 2015 18:38:56 +1000	[thread overview]
Message-ID: <20150318083856.GB23658@toto> (raw)
In-Reply-To: <1426526422-28338-1-git-send-email-peter.maydell@linaro.org>

On Mon, Mar 16, 2015 at 05:20:17PM +0000, Peter Maydell wrote:
> 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.

Hi Peter,

Generally I think the direction of this looks very good, thanks!

A few comments:

1. Would it make sense to instead of having the MemTxAttrs be
a uint64_t instead have them be a struct with bitfields?
We could still pass the struct by value I think and as long
as it doesn't grow large the compiler will emit similar or
the same code IIUC.

2. The series introduces the read and write _with_attrs. Another
approach could be to add a (for example) single .access callback.
The callback could take a structure pointer as input, e.g:

struct MemTx {
    bool rw;
    hwaddr addr;
    int size;
    uint64_t data;
    MemTxAttrs attrs;
}

MemTxResult access(MemTx *tx)

The benefit I see is that this will make it easier for us in the
future to add new fields if needed.

Best regards,
Edgar


> 
> (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
> 

  parent reply	other threads:[~2015-03-18  8:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 17:20 [Qemu-devel] [RFC 0/5] Memory transaction attributes API Peter Maydell
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 ` Edgar E. Iglesias [this message]
2015-03-18 10:23   ` [Qemu-devel] [RFC 0/5] Memory transaction attributes API 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=20150318083856.GB23658@toto \
    --to=edgar.iglesias@gmail.com \
    --cc=alex.bennee@linaro.org \
    --cc=greg.bellows@linaro.org \
    --cc=patches@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --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).