From: Stefan Hajnoczi <stefanha@redhat.com>
To: Alexander Bulekov <alxndr@bu.edu>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Mauro Matteo Cascella" <mcascell@redhat.com>,
"Qiuhao Li" <Qiuhao.Li@outlook.com>,
"Peter Xu" <peterx@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Li Qiang" <liq3ea@gmail.com>, "Thomas Huth" <thuth@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"Bandan Das" <bsd@redhat.com>,
"Edgar E . Iglesias" <edgar.iglesias@gmail.com>,
"Darren Kenny" <darren.kenny@oracle.com>,
"Bin Meng" <bin.meng@windriver.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>
Subject: Re: [PATCH v2] memory: prevent dma-reentracy issues
Date: Tue, 12 Jul 2022 10:34:48 +0100 [thread overview]
Message-ID: <Ys1AOOWLZRBxYNbC@stefanha-x1.localdomain> (raw)
In-Reply-To: <20220621155306.2mvr22dd5xuc6pqm@mozz.bu.edu>
[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]
On Tue, Jun 21, 2022 at 11:53:06AM -0400, Alexander Bulekov wrote:
> On 220621 1630, Peter Maydell wrote:
> > On Thu, 9 Jun 2022 at 14:59, Alexander Bulekov <alxndr@bu.edu> wrote:
> > > diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> > > index 44dacfa224..ab1ad0f7a8 100644
> > > --- a/include/hw/pci/pci.h
> > > +++ b/include/hw/pci/pci.h
> > > @@ -834,8 +834,17 @@ static inline MemTxResult pci_dma_rw(PCIDevice *dev, dma_addr_t addr,
> > > void *buf, dma_addr_t len,
> > > DMADirection dir, MemTxAttrs attrs)
> > > {
> > > - return dma_memory_rw(pci_get_address_space(dev), addr, buf, len,
> > > - dir, attrs);
> > > + bool prior_engaged_state;
> > > + MemTxResult result;
> > > +
> > > + prior_engaged_state = dev->qdev.engaged_in_io;
> > > +
> > > + dev->qdev.engaged_in_io = true;
> > > + result = dma_memory_rw(pci_get_address_space(dev), addr, buf, len,
> > > + dir, attrs);
> > > + dev->qdev.engaged_in_io = prior_engaged_state;
> > > +
> > > + return result;
> >
> > Why do we need to do something in this pci-specific function ?
> > I was expecting this to only need changes at the generic-to-all-devices
> > level.
>
> Both of these handle the BH->DMA->MMIO case. Unlike MMIO, I don't think
> there is any neat way to set the engaged_in_io flag as we enter a BH. So
> instead, we try to set it when a device initiates DMA.
>
> The pci function lets us do that since we get a glimpse of the dev/qdev
> (unlike the dma_memory_... functions).
...
> > > @@ -302,6 +310,10 @@ static MemTxResult dma_buf_rw(void *buf, dma_addr_t len, dma_addr_t *residual,
> > > xresidual -= xfer;
> > > }
> > >
> > > + if (dev) {
> > > + dev->engaged_in_io = prior_engaged_state;
> > > + }
> >
> > Not all DMA goes through dma_buf_rw() -- why does it need changes?
>
> This one has the same goal, but accesses the qdev through sg, instead of
> PCI.
Should dma_*() APIs take a reentrancy guard argument so that all DMA
accesses are systematically covered?
/* Define this in the memory API */
typedef struct {
bool engaged_in_io;
} MemReentrancyGuard;
/* Embed MemReentrancyGuard in DeviceState */
...
/* Require it in dma_*() APIs */
static inline MemTxResult dma_memory_rw(AddressSpace *as, dma_addr_t addr,
void *buf, dma_addr_t len,
DMADirection dir, MemTxAttrs attrs,
MemReentrancyGuard *guard);
/* Call dma_*() APIs like this... */
static inline MemTxResult pci_dma_rw(PCIDevice *dev, dma_addr_t addr,
void *buf, dma_addr_t len,
DMADirection dir, MemTxAttrs attrs)
{
return dma_memory_rw(pci_get_address_space(dev), addr, buf, len,
dir, attrs, &dev->qdev.reentrancy_guard);
}
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-07-12 9:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 13:58 [PATCH v2] memory: prevent dma-reentracy issues Alexander Bulekov
2022-06-20 14:06 ` Alexander Bulekov
2022-06-21 8:34 ` David Hildenbrand
2022-06-21 15:11 ` Alexander Bulekov
2022-06-21 15:30 ` Peter Maydell
2022-06-21 15:53 ` Alexander Bulekov
2022-07-12 9:34 ` Stefan Hajnoczi [this message]
2022-07-13 15:51 ` Alexander Bulekov
2022-07-13 17:31 ` Stefan Hajnoczi
2022-10-20 22:11 ` Alexander Bulekov
2022-10-24 18:46 ` Stefan Hajnoczi
2022-10-25 10:11 ` 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=Ys1AOOWLZRBxYNbC@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=Qiuhao.Li@outlook.com \
--cc=alxndr@bu.edu \
--cc=berrange@redhat.com \
--cc=bin.meng@windriver.com \
--cc=bsd@redhat.com \
--cc=darren.kenny@oracle.com \
--cc=david@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=liq3ea@gmail.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mcascell@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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).