All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ethan Chen via <qemu-riscv@nongnu.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Xu <peterx@redhat.com>, <qemu-devel@nongnu.org>,
	<richard.henderson@linaro.org>, <pbonzini@redhat.com>,
	<palmer@dabbelt.com>, <alistair.francis@wdc.com>,
	<in.meng@windriver.com>, <liweiwei@iscas.ac.cn>,
	<dbarboza@ventanamicro.com>, <hiwei_liu@linux.alibaba.com>,
	<qemu-riscv@nongnu.org>, <david@redhat.com>
Subject: Re: [PATCH v2 1/4] exec/memattrs: Add iopmp source id, start address, end address to MemTxAttrs
Date: Wed, 8 Nov 2023 15:33:32 +0800	[thread overview]
Message-ID: <ZUs5zCUcQphKuixV@ethan84-VirtualBox> (raw)
In-Reply-To: <CAFEAcA9J7euoRVCd8xm+UPVpOHNj7pBjvtqJXnGg_HtAV6f0YQ@mail.gmail.com>

On Tue, Nov 07, 2023 at 10:53:40AM +0000, Peter Maydell wrote:
> On Tue, 7 Nov 2023 at 03:02, Ethan Chen <ethan84@andestech.com> wrote:
> >
> > On Mon, Nov 06, 2023 at 10:34:41AM +0000, Peter Maydell wrote:
> > > What AXI bus signals? You already get address and size in the
> > > actual memory transaction, they don't need to go in the MemTxAttrs.
> > >
> >
> > A burst contains multiple continuous read or write operations. In current
> > transaction, I can only get the size and address of a single operation. IOPMP
> > checks not only a single operation but also the burst information. I propose
> > to add those signals to MemTxAttrs.
> 
> QEMU doesn't emulate bus transactions at that level -- we have
> no concept of burst transactions. You should have the IOMMU
> do whatever it would do for a series of simple transactions.
>

I propose to use another method like StreamSink in hw/dma/xilinx_axidma.c to
let DMA send the signals to IOPMP instead of modifying IOMMU.

Thanks,
Ethan Chen


WARNING: multiple messages have this Message-ID (diff)
From: Ethan Chen via <qemu-devel@nongnu.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Xu <peterx@redhat.com>, <qemu-devel@nongnu.org>,
	<richard.henderson@linaro.org>, <pbonzini@redhat.com>,
	<palmer@dabbelt.com>, <alistair.francis@wdc.com>,
	<in.meng@windriver.com>, <liweiwei@iscas.ac.cn>,
	<dbarboza@ventanamicro.com>, <hiwei_liu@linux.alibaba.com>,
	<qemu-riscv@nongnu.org>, <david@redhat.com>
Subject: Re: [PATCH v2 1/4] exec/memattrs: Add iopmp source id, start address, end address to MemTxAttrs
Date: Wed, 8 Nov 2023 15:33:32 +0800	[thread overview]
Message-ID: <ZUs5zCUcQphKuixV@ethan84-VirtualBox> (raw)
In-Reply-To: <CAFEAcA9J7euoRVCd8xm+UPVpOHNj7pBjvtqJXnGg_HtAV6f0YQ@mail.gmail.com>

On Tue, Nov 07, 2023 at 10:53:40AM +0000, Peter Maydell wrote:
> On Tue, 7 Nov 2023 at 03:02, Ethan Chen <ethan84@andestech.com> wrote:
> >
> > On Mon, Nov 06, 2023 at 10:34:41AM +0000, Peter Maydell wrote:
> > > What AXI bus signals? You already get address and size in the
> > > actual memory transaction, they don't need to go in the MemTxAttrs.
> > >
> >
> > A burst contains multiple continuous read or write operations. In current
> > transaction, I can only get the size and address of a single operation. IOPMP
> > checks not only a single operation but also the burst information. I propose
> > to add those signals to MemTxAttrs.
> 
> QEMU doesn't emulate bus transactions at that level -- we have
> no concept of burst transactions. You should have the IOMMU
> do whatever it would do for a series of simple transactions.
>

I propose to use another method like StreamSink in hw/dma/xilinx_axidma.c to
let DMA send the signals to IOPMP instead of modifying IOMMU.

Thanks,
Ethan Chen


  reply	other threads:[~2023-11-08  7:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02  9:40 [PATCH v2 0/4] Support RISC-V IOPMP Ethan Chen via
2023-11-02  9:40 ` Ethan Chen via
2023-11-02  9:40 ` [PATCH v2 1/4] exec/memattrs: Add iopmp source id, start address, end address to MemTxAttrs Ethan Chen via
2023-11-02  9:40   ` Ethan Chen via
2023-11-02 13:49   ` Peter Xu
2023-11-02 13:53     ` Peter Maydell
2023-11-03  3:29       ` Ethan Chen via
2023-11-03  3:29         ` Ethan Chen via
2023-11-03 10:34         ` Peter Maydell
2023-11-06  1:56           ` Ethan Chen via
2023-11-06  1:56             ` Ethan Chen via
2023-11-06 10:34             ` Peter Maydell
2023-11-07  3:01               ` Ethan Chen via
2023-11-07  3:01                 ` Ethan Chen via
2023-11-07 10:53                 ` Peter Maydell
2023-11-08  7:33                   ` Ethan Chen via [this message]
2023-11-08  7:33                     ` Ethan Chen via
2023-11-03  3:27     ` Ethan Chen via
2023-11-03  3:27       ` Ethan Chen via
2023-11-02  9:40 ` [PATCH v2 2/4] Add RISC-V IOPMP support Ethan Chen via
2023-11-02  9:40   ` Ethan Chen via
2023-11-02  9:40 ` [PATCH v2 3/4] hw/dma: Add Andes ATCDMAC300 support Ethan Chen via
2023-11-02  9:40   ` Ethan Chen via
2023-11-02  9:40 ` [PATCH v2 4/4] hw/riscv/virt: Add IOPMP support Ethan Chen via
2023-11-02  9:40   ` Ethan Chen via

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=ZUs5zCUcQphKuixV@ethan84-VirtualBox \
    --to=qemu-riscv@nongnu.org \
    --cc=alistair.francis@wdc.com \
    --cc=david@redhat.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=ethan84@andestech.com \
    --cc=hiwei_liu@linux.alibaba.com \
    --cc=in.meng@windriver.com \
    --cc=liweiwei@iscas.ac.cn \
    --cc=palmer@dabbelt.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.