From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: Neo Jia <cjia@nvidia.com>, Marc Zyngier <maz@kernel.org>,
Cornelia Huck <cohuck@redhat.com>,
qemu-devel@nongnu.org, dgilbert@redhat.com,
Shenming Lu <lushenming@huawei.com>,
qemu-arm@nongnu.org, yuzenghui@huawei.com,
wanghaibin.wang@huawei.com
Subject: Re: [PATCH RFC] vfio: Move the saving of the config space to the right place in VFIO migration
Date: Thu, 19 Nov 2020 10:41:27 -0700 [thread overview]
Message-ID: <20201119104127.5e243efa@w520.home> (raw)
In-Reply-To: <860bd707-8862-2584-6e12-67c86f092dba@nvidia.com>
On Thu, 19 Nov 2020 14:13:24 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 11/14/2020 2:47 PM, Shenming Lu wrote:
> > When running VFIO migration, I found that the restoring of VFIO PCI device’s
> > config space is before VGIC on ARM64 target. But generally, interrupt controllers
> > need to be restored before PCI devices.
>
> Is there any other way by which VGIC can be restored before PCI device?
>
> > Besides, if a VFIO PCI device is
> > configured to have directly-injected MSIs (VLPIs), the restoring of its config
> > space will trigger the configuring of these VLPIs (in kernel), where it would
> > return an error as I saw due to the dependency on kvm’s vgic.
> >
>
> Can this be fixed in kernel to re-initialize the kernel state?
>
> > To avoid this, we can move the saving of the config space from the iterable
> > process to the non-iterable process, so that it will be called after VGIC
> > according to their priorities.
> >
>
> With this change, at resume side, pre-copy phase data would reach
> destination without restored config space. VFIO device on destination
> might need it's config space setup and validated before it can accept
> further VFIO device specific migration state.
>
> This also changes bit-stream, so it would break migration with original
> migration patch-set.
Config space can continue to change while in pre-copy, if we're only
sending config space at the initiation of pre-copy, how are any changes
that might occur before the VM is stopped conveyed to the target? For
example the guest might reboot and a device returned to INTx mode from
MSI during pre-copy. Thanks,
Alex
> > Signed-off-by: Shenming Lu <lushenming@huawei.com>
> > ---
> > hw/vfio/migration.c | 22 ++++++----------------
> > 1 file changed, 6 insertions(+), 16 deletions(-)
> >
> > diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> > index 3ce285ea39..028da35a25 100644
> > --- a/hw/vfio/migration.c
> > +++ b/hw/vfio/migration.c
> > @@ -351,7 +351,7 @@ static int vfio_update_pending(VFIODevice *vbasedev)
> > return 0;
> > }
> >
> > -static int vfio_save_device_config_state(QEMUFile *f, void *opaque)
> > +static void vfio_save_device_config_state(QEMUFile *f, void *opaque)
> > {
> > VFIODevice *vbasedev = opaque;
> >
> > @@ -365,13 +365,14 @@ static int vfio_save_device_config_state(QEMUFile *f, void *opaque)
> >
> > trace_vfio_save_device_config_state(vbasedev->name);
> >
> > - return qemu_file_get_error(f);
> > + if (qemu_file_get_error(f))
> > + error_report("%s: Failed to save device config space",
> > + vbasedev->name);
> > }
> >
> > static int vfio_load_device_config_state(QEMUFile *f, void *opaque)
> > {
> > VFIODevice *vbasedev = opaque;
> > - uint64_t data;
> >
> > if (vbasedev->ops && vbasedev->ops->vfio_load_config) {
> > int ret;
> > @@ -384,15 +385,8 @@ static int vfio_load_device_config_state(QEMUFile *f, void *opaque)
> > }
> > }
> >
> > - data = qemu_get_be64(f);
> > - if (data != VFIO_MIG_FLAG_END_OF_STATE) {
> > - error_report("%s: Failed loading device config space, "
> > - "end flag incorrect 0x%"PRIx64, vbasedev->name, data);
> > - return -EINVAL;
> > - }
> > -
> > trace_vfio_load_device_config_state(vbasedev->name);
> > - return qemu_file_get_error(f);
> > + return 0;
> > }
> >
> > static int vfio_set_dirty_page_tracking(VFIODevice *vbasedev, bool start)
> > @@ -575,11 +569,6 @@ static int vfio_save_complete_precopy(QEMUFile *f, void *opaque)
> > return ret;
> > }
> >
> > - ret = vfio_save_device_config_state(f, opaque);
> > - if (ret) {
> > - return ret;
> > - }
> > -
> > ret = vfio_update_pending(vbasedev);
> > if (ret) {
> > return ret;
> > @@ -720,6 +709,7 @@ static SaveVMHandlers savevm_vfio_handlers = {
> > .save_live_pending = vfio_save_pending,
> > .save_live_iterate = vfio_save_iterate,
> > .save_live_complete_precopy = vfio_save_complete_precopy,
> > + .save_state = vfio_save_device_config_state,
> > .load_setup = vfio_load_setup,
> > .load_cleanup = vfio_load_cleanup,
> > .load_state = vfio_load_state,
> >
>
next prev parent reply other threads:[~2020-11-19 17:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-14 9:17 [PATCH RFC] vfio: Move the saving of the config space to the right place in VFIO migration Shenming Lu
2020-11-19 8:43 ` Kirti Wankhede
2020-11-19 17:41 ` Alex Williamson [this message]
2020-11-20 14:05 ` Shenming Lu
2020-11-20 22:01 ` Alex Williamson
2020-11-23 3:14 ` Shenming Lu
2020-11-23 19:33 ` Neo Jia
2020-11-23 21:46 ` Alex Williamson
2020-11-26 6:56 ` Shenming Lu
2020-11-30 17:03 ` Alex Williamson
2020-12-01 6:37 ` Shenming Lu
2020-12-01 22:21 ` Alex Williamson
2020-12-03 8:34 ` Shenming Lu
2020-12-02 10:55 ` Dr. David Alan Gilbert
2020-12-04 10:45 ` Shenming Lu
2020-11-24 11:01 ` Shenming Lu
2020-11-24 11:02 ` Dr. David Alan Gilbert
2020-11-23 13:52 ` Cornelia Huck
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=20201119104127.5e243efa@w520.home \
--to=alex.williamson@redhat.com \
--cc=cjia@nvidia.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kwankhede@nvidia.com \
--cc=lushenming@huawei.com \
--cc=maz@kernel.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wanghaibin.wang@huawei.com \
--cc=yuzenghui@huawei.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).