qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: Ani Sinha <ani@anisinha.ca>
Cc: Jens Freimann <jfreimann@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] failover: fix unplug pending detection
Date: Thu, 30 Sep 2021 11:48:45 +0200	[thread overview]
Message-ID: <ec216e3a-71a3-c7a5-628f-1871d063d2a2@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2109301450580.579856@anisinha-lenovo>

On 30/09/2021 11:24, Ani Sinha wrote:
> 
> 
> On Thu, 30 Sep 2021, Laurent Vivier wrote:
> 
>> Failover needs to detect the end of the PCI unplug to start migration
>> after the VFIO card has been unplugged.
>>
>> To do that, a flag is set in pcie_cap_slot_unplug_request_cb() and reset in
>> pcie_unplug_device().
>>
>> But since
>>      17858a169508 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
>> we have switched to ACPI unplug and these functions are not called anymore
>> and the flag not set. So failover migration is not able to detect if card
>> is really unplugged and acts as it's done as soon as it's started. So it
>> doesn't wait the end of the unplug to start the migration. We don't see any
>> problem when we test that because ACPI unplug is faster than PCIe native
>> hotplug and when the migration really starts the unplug operation is
>> already done.
>>
>> See c000a9bd06ea ("pci: mark device having guest unplug request pending")
>>      a99c4da9fc2a ("pci: mark devices partially unplugged")
> 
> Ok so I have a basic question about partially_hotplugged flag in the
> device struct (there were no comments added in a99c4da9fc2a39847
> explaining it). It seems we return early from pcie_unplug_device() when
> this flag is set from failover_unplug_primary() in virtio-net. What is the
> purpose of this flag? It seems we are not doing a full unplug of the
> primary device?

Yes, to be able to plug it back in case of migration failure we must keep all the data 
structures.

But reading the code again it seems this part should be in acpi_pcihp_eject_slot() rather 
than in acpi_pcihp_device_unplug_cb() to prevent the 
hotplug_handler_unplug()/object_unparent()  rather than the qdev_unrealize() (to be like 
in pcie.c).

Thanks,
Laurent



  reply	other threads:[~2021-09-30  9:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30  8:20 [PATCH] failover: fix unplug pending detection Laurent Vivier
2021-09-30  9:24 ` Ani Sinha
2021-09-30  9:48   ` Laurent Vivier [this message]
2021-10-01  5:19     ` Ani Sinha
2021-10-01  6:32       ` Laurent Vivier

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=ec216e3a-71a3-c7a5-628f-1871d063d2a2@redhat.com \
    --to=lvivier@redhat.com \
    --cc=ani@anisinha.ca \
    --cc=imammedo@redhat.com \
    --cc=jfreimann@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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).