On 11/25/19 6:14 PM, Cornelia Huck wrote:
Also, I'm wondering if we need special care for vfio-ap, although I'm
not sure if it is feasible to add migration support for it all. We
currently have a matrix device (always same parent) defined by the
UUID, and adapters/domains configured for this matrix device (which is
handled as extra parameters in the mdevctl device config). I'm not sure
how different adapters/domains translate between systems we want to
migrate between. Not sure how much sense it makes to dwell on this at
Aside from the card preparation with the appropriate masterkeys the
adapter/domain configuration (including the card types) for an mdev
needs to remain the same since there is no virtualization of
adapter/domain addresses in the current vfio-ap driver implementation.
As a result a currently possible migration scenario is cross-CEC.
From libvirts perspective:
Assuming that mdevs on the source and target system exist, would a
matching UUID be enough assurance that these two host resources match
for a migration? If not, is a check performed on the configuration of
the two mdevs? What is in that case considered migration save? Where are
these checks implemented? Does the checking for migratablity go beyond
the configuration data of mdev devices, e.g. vfio-ap: check for
existence of masterkeys, card type equivalency or as Connie mentioned
before on vfio-ccw the equivalency of the child ccw device of the
subchannels.
the moment, though; but IIRC, there were some pci devices wanting to
use extra parameters as well (and there was also that discussion about
how to support aggregation).
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
