qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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,
> >   
> 



  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).