qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, mst@redhat.com, jasowang@redhat.com,
	imammedo@redhat.com, alex.williamson@redhat.com, clg@redhat.com,
	philmd@linaro.org, zhenzhong.duan@intel.com, ddutile@redhat.com
Subject: Re: [PATCH 4/5] hw/arm/smmuv3: Move reset to exit phase
Date: Mon, 10 Feb 2025 09:18:43 -0500	[thread overview]
Message-ID: <Z6oKw8I3oijXMnCf@x1.local> (raw)
In-Reply-To: <3db2e0a7-0f38-4c6a-a9a4-d44e0c6af436@redhat.com>

On Mon, Feb 10, 2025 at 09:35:53AM +0100, Eric Auger wrote:
> Hi Peter,

Eric,

> 
> 
> On 2/7/25 6:47 PM, Peter Xu wrote:
> > On Fri, Feb 07, 2025 at 04:58:39PM +0000, Peter Maydell wrote:
> >> (I wonder if we ought to suggest quiescing outstanding
> >> DMA in the enter phase? But it's probably easier to fix
> >> the iommus like this series does than try to get every
> >> dma-capable pci device to do something different.)
> > I wonder if we should provide some generic helper to register vIOMMU reset
> > callbacks, so that we'll be sure any vIOMMU model impl that will register
> > at exit() phase only, and do nothing during the initial two phases.  Then
> > we can put some rich comment on that helper on why.
> As discussed with Cédric, I think it shall think about having eventually
> a base class for vIOMMU. Maybe this is something we can handle
> afterwards though.

Yes agreed.

> >
> > Looks like it means the qemu reset model in the future can be a combination
> > of device tree (which resets depth-first) and the three phases model.  We
> > will start to use different approach to solve different problems.
> >
> > Maybe after we settle our mind, we should update the reset document,
> > e.g. for device emulation developers, we need to be clear on where to
> > quiesce the DMAs, and it must not happen at exit().  Both all devices and
> > all iommu impls need to follow the rules to make it work like the plan.
> The 3 phase documentation already states that you shouldn't do anything
> in enter phase that can have side-effect on other devices. However I
> agree we can add another example besides the qemu_irq line one.

The document will be relevant to two sides of things (so far not relevant
to enter() phase, but more on what we should put into the last two phases
either for vIOMMU impl or a PCIe device impl), that I commented in the
other reply to Peter.  I am not sure whether we need such fine granule
document, but in all cases I agree this can definitely be done later. :)

Thanks!

-- 
Peter Xu



  reply	other threads:[~2025-02-10 14:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 14:21 [PATCH 0/5] Fix vIOMMU reset order Eric Auger
2025-02-06 14:21 ` [PATCH 1/5] hw/virtio/virtio-iommu: Migrate to 3-phase reset Eric Auger
2025-02-06 14:21 ` [PATCH 2/5] hw/i386/intel-iommu: " Eric Auger
2025-02-06 14:21 ` [PATCH 3/5] hw/i386/intel_iommu: Tear down address spaces before IOMMU reset Eric Auger
2025-02-17  3:02   ` Duan, Zhenzhong
2025-02-17  7:31     ` Eric Auger
2025-02-06 14:21 ` [PATCH 4/5] hw/arm/smmuv3: Move reset to exit phase Eric Auger
2025-02-07 16:37   ` Peter Maydell
2025-02-07 16:50     ` Eric Auger
2025-02-07 16:58       ` Peter Maydell
2025-02-07 17:47         ` Peter Xu
2025-02-07 18:18           ` Peter Maydell
2025-02-10  8:47             ` Eric Auger
2025-02-10 14:14             ` Peter Xu
2025-02-10 14:22               ` Peter Maydell
2025-02-12 17:28                 ` Cédric Le Goater
2025-02-10  8:35           ` Eric Auger
2025-02-10 14:18             ` Peter Xu [this message]
2025-02-10  8:40         ` Eric Auger
2025-02-06 14:21 ` [PATCH 5/5] hw/vfio/common: Add a trace point in vfio_reset_handler Eric Auger
2025-02-07 17:18   ` Cédric Le Goater
2025-02-07 11:09 ` [PATCH 0/5] Fix vIOMMU reset order Michael S. Tsirkin
2025-02-07 16:40   ` Peter Maydell
2025-02-07 16:52     ` Eric Auger
2025-02-07 16:54 ` Peter Xu
2025-02-07 17:06   ` Peter Maydell
2025-02-07 17:31     ` Peter Xu
2025-02-10  8:45       ` Eric Auger
2025-02-07 17:25   ` Cédric Le Goater
2025-02-10  8:49     ` Eric Auger

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=Z6oKw8I3oijXMnCf@x1.local \
    --to=peterx@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=zhenzhong.duan@intel.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).