All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Eric Auger <eric.auger@redhat.com>
Cc: lvivier@redhat.com, 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: Tue, 15 Feb 2022 12:58:47 +0100	[thread overview]
Message-ID: <87leycs5mw.fsf@redhat.com> (raw)
In-Reply-To: <Ygt3A4jETnmy0K0Y@myrica>

On Tue, Feb 15 2022, Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:

> On Tue, Feb 15, 2022 at 10:16:40AM +0100, Eric Auger wrote:
>> Hi Connie,
>> 
>> On 2/14/22 6:34 PM, Cornelia Huck wrote:
>> > 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 :)
>> As nobody has shout and we are not aware of anybody using the device in
>> production mode yet due to the missing boot bypass feature this series
>> brings, I would be personally in favour of leaving things as is. Now, up
>> to Jean if he wants to go and implement your suggestion.
>
> I agree, it seems too unlikely that someone would want to migrate it back
> to 6.2 where it wasn't really useable except for experiments

Fair enough. Let's make this an

Acked-by: Cornelia Huck <cohuck@redhat.com>

(for the series)



  reply	other threads:[~2022-02-15 12:01 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 ` [PATCH v3 0/4] virtio-iommu: Support VIRTIO_IOMMU_F_BYPASS_CONFIG Cornelia Huck
2022-02-15  9:16   ` Eric Auger
2022-02-15  9:48     ` Jean-Philippe Brucker
2022-02-15 11:58       ` Cornelia Huck [this message]
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=87leycs5mw.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.