From: Cornelia Huck <cohuck@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>, eric.auger@redhat.com
Cc: lvivier@redhat.com,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
thuth@redhat.com, mst@redhat.com, qemu-devel@nongnu.org,
dgilbert@redhat.com, pasic@linux.ibm.com, pbonzini@redhat.com
Subject: Re: [PATCH v3 0/4] virtio-iommu: Support VIRTIO_IOMMU_F_BYPASS_CONFIG
Date: Mon, 14 Feb 2022 18:34:11 +0100 [thread overview]
Message-ID: <87o839s67g.fsf@redhat.com> (raw)
In-Reply-To: <20220214124356.872985-1-jean-philippe@linaro.org>
On Mon, Feb 14 2022, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> Replace the VIRTIO_IOMMU_F_BYPASS feature with
> VIRTIO_IOMMU_F_BYPASS_CONFIG, which enables a config space bit to switch
> global bypass on and off.
>
> Add a boot-bypass option, which defaults to 'on' to be in line with
> other vIOMMUs and to allow running firmware/bootloader that are unaware
> of the IOMMU. x86 doesn't need a workaround to boot with virtio-iommu
> anymore.
>
> Since v2 [1]:
> * Added the new bypass bits to the migration stream.
> As discussed on the v2 thread, we assume that cross-version
> compatibility is not required for live migration at the moment, so we
> only increase the version number. Patch 2 says: "We add the bypass
> field to the migration stream without introducing subsections, based
> on the assumption that this virtio-iommu device isn't being used in
> production enough to require cross-version migration at the moment
> (all previous version required workarounds since they didn't support
> ACPI and boot-bypass)."
>
> [1] https://lore.kernel.org/qemu-devel/20220127142940.671333-1-jean-philippe@linaro.org/
One thing that we could do to avoid surprises in the unlikely case that
somebody has a virtio-iommu device and wants to migrate to an older
machine version is to add a migration blocker for the virtio-iommu
device for all compat machines for versions 6.2 or older (i.e. only 7.0
or newer machine types can have a migratable virtio-iommu device
starting with QEMU 7.0.) Not too complicated to implement, but I'm not
sure whether we'd add too much code to prevent something very unlikely
to happen anyway. I would not insist on it :)
Otherwise, I didn't spot problems in this series.
next prev parent reply other threads:[~2022-02-14 17:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 12:43 [PATCH v3 0/4] virtio-iommu: Support VIRTIO_IOMMU_F_BYPASS_CONFIG Jean-Philippe Brucker
2022-02-14 12:43 ` [PATCH v3 1/4] linux-headers: update to v5.17-rc1 Jean-Philippe Brucker
2022-02-14 12:43 ` [PATCH v3 2/4] virtio-iommu: Default to bypass during boot Jean-Philippe Brucker
2022-02-14 12:43 ` [PATCH v3 3/4] virtio-iommu: Support bypass domain Jean-Philippe Brucker
2022-02-14 12:43 ` [PATCH v3 4/4] tests/qtest/virtio-iommu-test: Check bypass config Jean-Philippe Brucker
2022-02-21 9:11 ` Thomas Huth
2022-02-14 17:34 ` Cornelia Huck [this message]
2022-02-15 9:16 ` [PATCH v3 0/4] virtio-iommu: Support VIRTIO_IOMMU_F_BYPASS_CONFIG Eric Auger
2022-02-15 9:48 ` Jean-Philippe Brucker
2022-02-15 11:58 ` Cornelia Huck
2022-02-15 9:25 ` Eric Auger
2022-02-15 9:49 ` Jean-Philippe Brucker
2022-03-03 11:41 ` Jean-Philippe Brucker
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=87o839s67g.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eric.auger@redhat.com \
--cc=jean-philippe@linaro.org \
--cc=lvivier@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@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 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.