Hi, On 2/9/22 12:10 PM, Cornelia Huck wrote: > On Tue, Feb 08 2022, "Michael S. Tsirkin" <m...@redhat.com> wrote: > >> On Tue, Feb 08, 2022 at 06:42:57PM +0100, Cornelia Huck wrote: >>> On Thu, Jan 27 2022, Jean-Philippe Brucker <jean-phili...@linaro.org> wrote: >>> >>>> @@ -988,9 +1025,9 @@ static void virtio_iommu_device_realize(DeviceState >>>> *dev, Error **errp) >>>> virtio_add_feature(&s->features, VIRTIO_IOMMU_F_INPUT_RANGE); >>>> virtio_add_feature(&s->features, VIRTIO_IOMMU_F_DOMAIN_RANGE); >>>> virtio_add_feature(&s->features, VIRTIO_IOMMU_F_MAP_UNMAP); >>>> - virtio_add_feature(&s->features, VIRTIO_IOMMU_F_BYPASS); >>>> virtio_add_feature(&s->features, VIRTIO_IOMMU_F_MMIO); >>>> virtio_add_feature(&s->features, VIRTIO_IOMMU_F_PROBE); >>>> + virtio_add_feature(&s->features, VIRTIO_IOMMU_F_BYPASS_CONFIG); >>> Hm. In the other patch, you say that you don't support cross-version >>> migration (I assume across QEMU versions?) >> I missed that ... where does it say this? > In bf447d9b-c039-ccdc-f24f-ab8b56c1b...@redhat.com and follow-ups > (unless I misread that; maybe it's more about this concrete boundary and > not generally?)
We were considering the virtio-iommu QEMU device currently isn't used for production yet, as far as we know, because we were missing the ACPI integration. So we envisionned to not care about mig subsections and just add the new field in the VMState. would that make sense? Thanks Eric > >>> Because changing the feature >>> set will be guest-visible, and would need some compat handling if you >>> plan to support this.
