On Wed, Feb 09 2022, Eric Auger <eric.au...@redhat.com> wrote: > 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?
If people are currently mostly playing with this device, it would not hurt too much, I guess. (Should we document expectations somewhere?) Adding a compat prop for this feature would be easy enough, but juggling subsections is a bit more involved, so I see the argument for not caring about them. > > Thanks > > Eric > >> >>>> Because changing the feature >>>> set will be guest-visible, and would need some compat handling if you >>>> plan to support this.
