[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] [PATCH] s390x/pci: mark zpci devices as un
From: |
Cornelia Huck |
Subject: |
Re: [qemu-s390x] [Qemu-devel] [PATCH] s390x/pci: mark zpci devices as unmigratable |
Date: |
Fri, 1 Feb 2019 18:13:55 +0100 |
On Fri, 1 Feb 2019 17:06:26 +0100
David Hildenbrand <address@hidden> wrote:
> On 01.02.19 16:41, Collin Walling wrote:
> > On 2/1/19 7:45 AM, Cornelia Huck wrote:
> >> We currently don't migrate any state for zpci devices, which are
> >> coupled with standard pci devices. This means funny things happen
> >> when we e.g. try to migrate with a virtio-pci device but the s390x-
> >> specific zpci state is not migrated (vfio-pci is not affected, as
> >> it is not migratable anyway.)
> >>
> >> Until this is fixed, mark zpci devices as unmigratable.
> >>
> >> Reported-by: David Hildenbrand <address@hidden>
> >> Signed-off-by: Cornelia Huck <address@hidden>
> >> ---
> >>
> >> This is just a stop-gap measure to give us time to implement the
> >> needed migration code properly.
> >
> > I imagine this means we'll want a single migration handler that will
> > take care of PCI and zPCI in one go, that way the data stays coupled?
> >
> > Just throwing thoughts out there.
>
> Guess this won't really be possible. Each device is to migrate "itself".
> We'll then also have to see which parts of the host bridge requires
> migration. Most probably not that easy. Migrating timers and such.
> Taking care of resets...
>
> As I am planning to end my journey to wondeful zpci land for now (but I
> might eventually look into it again in the future), I won't be looking
> into migration.
>
> If IBM has some resources for that, very much appreciated.
And I'd be happy to queue such patches (just as I did right now for
this patch :)