All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shenming Lu <lushenming@huawei.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	Tarun Gupta <targupta@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Kunkun Jiang <jiangkunkun@huawei.com>,
	cjia@nvidia.com, quintela@redhat.com,
	Keqian Zhu <zhukeqian1@huawei.com>,
	cohuck@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com,
	Kirti Wankhede <kwankhede@nvidia.com>,
	dnigam@nvidia.com,
	"wanghaibin.wang@huawei.com" <wanghaibin.wang@huawei.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Yan Zhao <yan.y.zhao@intel.com>,
	philmd@redhat.com
Subject: Re: [PATCH v1 1/1] vfio: Make migration support non experimental by default.
Date: Fri, 12 Mar 2021 10:47:39 +0800	[thread overview]
Message-ID: <c428fba8-d84a-d1bc-bba3-276f60e7ff94@huawei.com> (raw)
In-Reply-To: <20210308155117.035c1408@omen.home.shazbot.org>

On 2021/3/9 6:51, Alex Williamson wrote:
> [Cc +Intel]
> 
> On Mon, 8 Mar 2021 21:39:49 +0530
> Tarun Gupta <targupta@nvidia.com> wrote:
> 
>> VFIO migration support in QEMU is experimental as of now, which was done to
>> provide soak time and resolve concerns regarding bit-stream.
>> But, with the patches discussed in
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg784931.html , we have
>> corrected ordering of saving PCI config space and bit-stream.
>>
>> So, this patch proposes to make vfio migration support in QEMU to be enabled
>> by default. Tested by successfully migrating mdev device.
>>
>> Signed-off-by: Tarun Gupta <targupta@nvidia.com>
>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
>> ---
>>  hw/vfio/pci.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index f74be78209..15e26f460b 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -3199,7 +3199,7 @@ static Property vfio_pci_dev_properties[] = {
>>      DEFINE_PROP_BIT("x-igd-opregion", VFIOPCIDevice, features,
>>                      VFIO_FEATURE_ENABLE_IGD_OPREGION_BIT, false),
>>      DEFINE_PROP_BOOL("x-enable-migration", VFIOPCIDevice,
>> -                     vbasedev.enable_migration, false),
>> +                     vbasedev.enable_migration, true),
>>      DEFINE_PROP_BOOL("x-no-mmap", VFIOPCIDevice, vbasedev.no_mmap, false),
>>      DEFINE_PROP_BOOL("x-balloon-allowed", VFIOPCIDevice,
>>                       vbasedev.ram_block_discard_allowed, false),
> 
> Looking back at the commit where this was added:
> 
> commit cf254988a50d4164c86a356c80b8d3ae0ccaa005
> Author: Alex Williamson <alex.williamson@redhat.com>
> Date:   Mon Nov 9 11:56:02 2020 -0700
> 
>     vfio: Make migration support experimental
>     
>     Support for migration of vfio devices is still in flux.  Developers
>     are attempting to add support for new devices and new architectures,
>     but none are yet readily available for validation.  We have concerns
>     whether we're transferring device resources at the right point in the
>     migration, whether we're guaranteeing that updates during pre-copy are
>     migrated, and whether we can provide bit-stream compatibility should
>     any of this change.  Even the question of whether devices should
>     participate in dirty page tracking during pre-copy seems contentious.
>     In short, migration support has not had enough soak time and it feels
>     premature to mark it as supported.
>     
>     Create an experimental option such that we can continue to develop.
>     
>     [Retaining previous acks/reviews for a previously identical code
>      change with different specifics in the commit log.]
>     
>     Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
>     Acked-by: Cornelia Huck <cohuck@redhat.com>
>     Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> 
> 
> What has tangibly changed since then?  I think we have patches on-list
> to address the known issue of PCI config space (MSI) ordering, which
> related to enabling migration on ARM platforms.  Do we have
> significantly more confidence in our ability to make compatible
> enhancement to the migration bitstream?  This was a particularly
> troublesome point for me if we have any hope of calling this
> supportable.  As far as I know, there are still no open source vendor
> drivers supporting migration for community testing.  We're also still
> missing the documentation that was promised previously, as Connie noted.
> 
> Huawei and Intel, what's your confidence level and what can you share
> regarding support for this implementation?  Thanks,

We have sent a number of patches regarding VFIO migration from our own test
(the support for this in our accelerator driver is still in experiment),
some of them are still on-list []...

[] https://lore.kernel.org/qemu-devel/20210310094106.2191-2-jiangkunkun@huawei.com/
   https://lore.kernel.org/linux-arm-kernel/20210126124444.27136-1-zhukeqian1@huawei.com/

Thanks,
Shenming

> 
> Alex
> 
> .
> 


  parent reply	other threads:[~2021-03-12  2:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08 16:09 [PATCH v1 1/1] vfio: Make migration support non experimental by default Tarun Gupta
2021-03-08 16:36 ` Daniel P. Berrangé
2021-03-08 23:05   ` Alex Williamson
2021-03-08 16:49 ` Cornelia Huck
2021-03-08 22:51 ` Alex Williamson
2021-03-12  2:12   ` Tian, Kevin
2021-03-12  2:47   ` Shenming Lu [this message]
2021-07-10  7:44 ` Claudio Fontana
2021-07-14 10:19   ` Kirti Wankhede
2021-07-22  0:42     ` Liang Yan

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=c428fba8-d84a-d1bc-bba3-276f60e7ff94@huawei.com \
    --to=lushenming@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=cjia@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dnigam@nvidia.com \
    --cc=jiangkunkun@huawei.com \
    --cc=kevin.tian@intel.com \
    --cc=kwankhede@nvidia.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=targupta@nvidia.com \
    --cc=wanghaibin.wang@huawei.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhukeqian1@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.