On Mon, Jun 20, 2011 at 3:05 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: > On 2011-06-19 22:46, Cam Macdonell wrote: >> On Thu, Jun 9, 2011 at 2:39 PM, Jan Kiszka <jan.kis...@web.de> wrote: >>> On 2011-06-09 22:00, Anthony Liguori wrote: >>>> On 06/09/2011 11:44 AM, Jan Kiszka wrote: >>>>> A first step towards getting rid of register_device_unmigratable >>>>> (ivshmem and lacking vmstate support in virtio are blocking this): >>>>> >>>>> Allow to register an unmigratable vmstate via qdev, i.e. tag a device >>>>> declaratively. >>>> >>>> I thought part of the problem with this was that for some devices (like >>>> ivshmem), whether it can be migrated was dynamic. It depends on >>>> configuration, state, etc. >>> >>> That only applies to ivshmem (the other user is device assignment which >>> is unconditionally unmigratable). And the ivshmem issue could easily be >>> solved by defining two devices, ivshmem-peer (or just ivshmem) and >>> ivshmem-master, eliminating the need for the role property. >>> >>> I don't think there will ever be a use case for a "transformer" device >>> that becomes unmigratable during runtime (would be a nightmare for >>> management apps anyway). >>> >>> If breaking the user interface of ivshmem for this is OK, I'll post a patch. >>> >>> Jan >>> >>> >> >> The migratability of ivshmem is not dynamic in that it doesn't change >> at runtime, it's set when the device is created, either role=peer or >> role=master is specified. So iiuc, this could work with ivshmem. > > So you are fine with breaking the interface? Everyone else as well? Then > I'll cook a patch to sort at least this out for 0.15. >
To be clear, this would break the interface in that a device cannot specify whether it's migratable via a parameter? > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > >
