qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: "Cédric Le Goater" <clg@redhat.com>, "Peter Xu" <peterx@redhat.com>
Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, peter.maydell@linaro.org, mst@redhat.com,
	jasowang@redhat.com, imammedo@redhat.com,
	alex.williamson@redhat.com, philmd@linaro.org,
	zhenzhong.duan@intel.com, ddutile@redhat.com
Subject: Re: [PATCH 0/5] Fix vIOMMU reset order
Date: Mon, 10 Feb 2025 09:49:34 +0100	[thread overview]
Message-ID: <c6b63631-181c-4cad-b542-5fc89f6d066d@redhat.com> (raw)
In-Reply-To: <2a18c763-cde4-4798-8866-3e023fc6ffc3@redhat.com>

Hi Cédric,


On 2/7/25 6:25 PM, Cédric Le Goater wrote:
> On 2/7/25 17:54, Peter Xu wrote:
>> On Thu, Feb 06, 2025 at 03:21:51PM +0100, Eric Auger wrote:
>>> This is a follow-up of Peter's attempt to fix the fact that
>>> vIOMMUs are likely to be reset before the device they protect:
>>>
>>> [PATCH 0/4] intel_iommu: Reset vIOMMU after all the rest of devices
>>> https://lore.kernel.org/all/20240117091559.144730-1-peterx@redhat.com/
>>>
>>> This is especially observed with virtio devices when a qmp system_reset
>>> command is sent but also with VFIO devices.
>>>
>>> This series puts the vIOMMU reset in the 3-phase exit callback.
>>>
>>> This scheme was tested successful with virtio-devices and some
>>> VFIO devices. Nevertheless not all the topologies have been
>>> tested yet.
>>
>> Eric,
>>
>> It's great to know that we seem to be able to fix everything in such
>> small
>> changeset!
>>
>> I would like to double check two things with you here:
>>
>>    - For VFIO's reset hook, looks like we have landed more changes so
>> that
>>      vfio's reset function is now a TYPE_LEGACY_RESET, and it always
>> do the
>>      reset during "hold" phase only (via legacy_reset_hold()).  That
>> part
>>      will make sure vIOMMU (if switching to exit()-only reset) will
>> order
>>      properly with VFIO.  Is my understanding correct here?
>
>
> Eric,
>
> We were still seeing DMA errors from VFIO devices :
>
>   VFIO_MAP_DMA failed: Bad address
>
> with this series at shutdown (machine or OS) when using an intel_iommu
> device. We could see that the VIOMMU was reset and the device DMAs
> were still alive. Do you know why now ?

I have started debugging this other case. At first sight this looks like
a different problem. First this occurs on a qmp system_powerdown
The error messages do not occur on qemu reset but rather as a result of
the guest disabling the intel iommu anc curiously when the aliased IOMMU
MR (nodma) is re-enabled. I need more time to debug this.

Eric

>
> Thanks,
>
> C.
>
>
>>
>>    - Is it possible if some PCIe devices that will provide its own
>>      phase.exit(), would it matter on the order of PCIe device's
>>      phase.exit() and vIOMMU's phase.exit() (if vIOMMUs switch to use
>>      exit()-only approach like this one)?
>>
>> PS: it would be great to attach such information in either cover
>> letter or
>> commit message.  But definitely not a request to repost the patchset, if
>> Michael would have Message-ID when merge that'll be far enough to help
>> anyone find this discussion again.
>>
>> Thanks!
>>
>



      reply	other threads:[~2025-02-10  8:50 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
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 [this message]

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=c6b63631-181c-4cad-b542-5fc89f6d066d@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=imammedo@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --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).