qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	Collin Walling <walling@linux.ibm.com>,
	Thomas Huth <thuth@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Richard Henderson <rth@twiddle.net>,
	Pierre Morel <pmorel@linux.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag
Date: Fri, 1 Feb 2019 11:08:59 +0100	[thread overview]
Message-ID: <20190201110859.7481c5be.cohuck@redhat.com> (raw)
In-Reply-To: <9ab3f62f-9011-b4af-2221-075d36d47327@redhat.com>

On Thu, 31 Jan 2019 22:21:01 +0100
David Hildenbrand <david@redhat.com> wrote:

> Thinking out loud:
> 
> We should migrate the flag in the future. This is already a problem
> right now, as the timer is also not migrated.
> 
> If the unplug request is sent and we migrate before the guest can react,
> the unplug would not happen.
> 
> However, looks like migration of zpci devices is not implemented _at all_.

Oh, joy.

> 
> This does not matter for pci passthrough (main use case). But when
> wanting to use e.g. virtio-pci-net, things are shaky after migration.
> 
> So this is future work.
> 

Hopefully folks running s390x guests are rather using virtio-ccw
devices anyway...

I agree that this needs to be taken care of on top of these changes.
Should we mark zpci devices unmigratable, or does it work for some
values of "work"?

  reply	other threads:[~2019-02-01 10:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 15:57 [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches David Hildenbrand
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 1/6] s390x/pci: Fix primary bus number for PCI bridges David Hildenbrand
2019-02-04 22:58   ` Collin Walling
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 2/6] s390x/pci: Fix hotplugging of " David Hildenbrand
2019-02-04 22:48   ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-02-04 23:43     ` David Hildenbrand
2019-02-05  9:24       ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 3/6] s390x/pci: Warn when adding PCI devices without the 'zpci' feature David Hildenbrand
2019-02-04 20:19   ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-02-04 21:54     ` David Hildenbrand
2019-02-04 22:42       ` Collin Walling
2019-02-04 22:45         ` David Hildenbrand
2019-02-05  9:32           ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 4/6] s390x/pci: Introduce unplug requests and split unplug handler David Hildenbrand
2019-01-31 20:40   ` Collin Walling
2019-01-31 21:11     ` David Hildenbrand
2019-02-01 10:38   ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 5/6] s390x/pci: Drop release timer and replace it with a flag David Hildenbrand
2019-01-31 20:33   ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:12     ` David Hildenbrand
2019-01-31 21:21   ` [Qemu-devel] " David Hildenbrand
2019-02-01 10:08     ` Cornelia Huck [this message]
2019-02-01 10:37       ` David Hildenbrand
2019-02-01 10:42         ` Cornelia Huck
2019-02-01 10:39   ` Cornelia Huck
2019-01-30 15:57 ` [Qemu-devel] [PATCH v2 6/6] s390x/pci: Unplug remaining requested devices on pcihost reset David Hildenbrand
2019-01-31 20:26   ` Collin Walling
2019-01-31 21:13     ` David Hildenbrand
2019-02-01 10:19   ` Cornelia Huck
2019-02-01 15:06     ` David Hildenbrand
2019-02-05  9:35       ` Cornelia Huck
2019-01-30 16:27 ` [Qemu-devel] [PATCH v2 0/6] s390x/pci: remaining hot/un)plug patches Cornelia Huck
2019-01-31 20:43 ` [Qemu-devel] [qemu-s390x] " Collin Walling
2019-01-31 21:21   ` David Hildenbrand
2019-02-01  8:35   ` Cornelia Huck
2019-02-01  9:18     ` David Hildenbrand
2019-02-01 15:44       ` Collin Walling
2019-02-05  9:55 ` [Qemu-devel] " Cornelia Huck
2019-02-05  9:55   ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190201110859.7481c5be.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=pmorel@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=thuth@redhat.com \
    --cc=walling@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).