All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Alexander Bulekov <alxndr@bu.edu>
Cc: "Fiona Ebner" <f.ebner@proxmox.com>,
	qemu-devel@nongnu.org, "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Mauro Matteo Cascella" <mcascell@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.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>,
	"Jon Maloy" <jmaloy@redhat.com>, "Siqi Chen" <coc.cyqh@gmail.com>,
	"Fam Zheng" <fam@euphon.net>
Subject: Re: [PATCH v6 1/4] memory: prevent dma-reentracy issues
Date: Fri, 10 Mar 2023 13:37:35 +0000	[thread overview]
Message-ID: <CAFEAcA-Laf223PWqLT1jZ0eFfGFK-c9VhAf8X-i=NFF5xhJbLg@mail.gmail.com> (raw)
In-Reply-To: <20230310132858.dljb2wgx325shtgd@mozz.bu.edu>

On Fri, 10 Mar 2023 at 13:29, Alexander Bulekov <alxndr@bu.edu> wrote:
>
> On 230310 0802, Alexander Bulekov wrote:
> > On 230310 1245, Peter Maydell wrote:
> > > On Fri, 10 Mar 2023 at 12:32, Alexander Bulekov <alxndr@bu.edu> wrote:
> > > > This MR seems to be "lsi-ram".
> > > >
> > > > From hw/scsi/lsi53c895a.c:
> > > >
> > > > memory_region_init_io(&s->ram_io, OBJECT(s), &lsi_ram_ops, s,
> > > >         "lsi-ram", 0x2000);
> > > >
> > > > So the LSI device is reading an LSI "Script" from its own IO region.. In
> > > > this particular case, I think there was no reason to use
> > > > memory_region_init_io rather than memory_region_init_ram, but this makes
> > > > me worried that there are other devices that use something like this.
> > >
> > > This particular device predates the entire MemoryRegion set of
> > > abstractions, so it might have seemed easier at the time.
> > > The endianness handling of the current code is also a bit
> > > confusing and might make it tricky to convert to a RAM MR.
> >
> > With my trivial mr_io - > mr_ram conversion, I no longer hit the
> > re-entrancy tracepoint, and my livecd boots, but it's probably not
> > exhaustively using the script functionality..
> >
> > Does the endianness actually cause a problem? As long as all accesses
> > (CPU -> LSI_RAM and LSI -> LSI_RAM) occur through the address_space API,
> > are we safe?

I'm not sure -- I looked at the code and I wasn't confident
on exactly what the combination of the DEVICE_LITTLE_ENDIAN
MemoryRegion and the use of stn_le_p/ldn_le_p would be.
I think it ought to be possible to use a RAM MR, but we'd
need to check the handling on both BE and LE hosts. Migration
compatibility is the other thing we would need to check, to
avoid accidentally switching from "script_ram[] contents are
in order X" to "they are in order Y"...

> Or maybe a rom_device with memory_region_rom_device_set_romd(romd_mode =
> false) is better here?

I don't think that helps -- if we can let the guest do direct
reads from the region then it's equally OK to let it do
direct writes, so we could just use a RAM MR.

-- PMM


  reply	other threads:[~2023-03-10 13:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05  4:07 [PATCH v6 0/4] memory: prevent dma-reentracy issues Alexander Bulekov
2023-02-05  4:07 ` [PATCH v6 1/4] " Alexander Bulekov
2023-03-10 11:14   ` Fiona Ebner
2023-03-10 12:23     ` Alexander Bulekov
2023-03-10 12:31       ` Alexander Bulekov
2023-03-10 12:45         ` Peter Maydell
2023-03-10 13:02           ` Alexander Bulekov
2023-03-10 13:28             ` Alexander Bulekov
2023-03-10 13:37               ` Peter Maydell [this message]
2023-03-10 13:07           ` Mark Cave-Ayland
2023-02-05  4:07 ` [PATCH v6 2/4] async: Add an optional reentrancy guard to the BH API Alexander Bulekov
2023-02-05  4:07 ` [PATCH v6 3/4] checkpatch: add qemu_bh_new/aio_bh_new checks Alexander Bulekov
2023-02-05  4:07 ` [PATCH v6 4/4] hw: replace most qemu_bh_new calls with qemu_bh_new_guarded Alexander Bulekov
2023-03-01 20:54   ` Michael S. Tsirkin
2023-03-02  9:25     ` Paul Durrant
2023-03-08 13:40   ` Alexander Bulekov
2023-03-10 10:38   ` Thomas Huth
2023-02-13  2:11 ` [PATCH v6 0/4] memory: prevent dma-reentracy issues Alexander Bulekov
2023-02-13 20:26   ` Michael S. Tsirkin
2023-02-16 11:14   ` Thomas Huth
2023-02-28 16:07     ` Alexander Bulekov
2023-02-28 16:28       ` Peter Xu
2023-02-13 14:58 ` Darren Kenny
2023-02-22 14:13 ` Stefan Hajnoczi
2023-03-01 20:55 ` Michael S. Tsirkin

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='CAFEAcA-Laf223PWqLT1jZ0eFfGFK-c9VhAf8X-i=NFF5xhJbLg@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=alxndr@bu.edu \
    --cc=berrange@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=bsd@redhat.com \
    --cc=coc.cyqh@gmail.com \
    --cc=darren.kenny@oracle.com \
    --cc=david@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=eduardo@habkost.net \
    --cc=f.ebner@proxmox.com \
    --cc=fam@euphon.net \
    --cc=jasowang@redhat.com \
    --cc=jmaloy@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mcascell@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --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 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.