All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liang Yan <lyan@suse.de>
To: Kirti Wankhede <kwankhede@nvidia.com>,
	Claudio Fontana <cfontana@suse.de>,
	Tarun Gupta <targupta@nvidia.com>,
	alex.williamson@redhat.com, qemu-devel@nongnu.org
Cc: cjia@nvidia.com, quintela@redhat.com, cohuck@redhat.com,
	dgilbert@redhat.com, lushenming@huawei.com, dnigam@nvidia.com,
	philmd@redhat.com
Subject: Re: [PATCH v1 1/1] vfio: Make migration support non experimental by default.
Date: Wed, 21 Jul 2021 20:42:39 -0400	[thread overview]
Message-ID: <7bf462b9-6e79-d768-1e1a-8a1b78298cc9@suse.de> (raw)
In-Reply-To: <a68d1ead-cca6-ff5e-033e-15865941500b@nvidia.com>


On 7/14/21 6:19 AM, Kirti Wankhede wrote:
>
>
> On 7/10/2021 1:14 PM, Claudio Fontana wrote:
>> On 3/8/21 5:09 PM, Tarun Gupta 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fqemu-devel%40nongnu.org%2Fmsg784931.html&amp;data=04%7C01%7Ckwankhede%40nvidia.com%7C98194e8a856f4e6b611c08d943769ab5%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637614998961553398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=A2EY9LEqGE0BSrT25h2WtWonb5oi0O%2B6%2BQmvhVf8Wd4%3D&amp;reserved=0
>>> , 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("", 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),
>>>
>>
>> Hello,
>>
>> has plain snapshot been tested?
>
> Yes.
>
>> If I issue the HMP command "savevm", and then "loadvm", will things
>> work fine?
>
> Yes
>

Hello Kirti,

I enabled x-enable-migration and did some hack on failover_pair_id,
finally made  "virsh save/restore" and "savevm/loadvm"work through.
However, it seems vGPU did not get involved in the real migration
process, the qemu trace file confirmed it, there is no vfio section for
savevm_section_start at all.

I am using kernel 5.8 and latest qemu, vGPU 12.2 with one V100. I am
wondering if there is a version compatible requirement or need extra
setup. Could you share your test setup here? Thanks in advance.

Regards,

Liang



> Thanks,
> Kirti
>


      reply	other threads:[~2021-07-22  0:43 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
2021-07-10  7:44 ` Claudio Fontana
2021-07-14 10:19   ` Kirti Wankhede
2021-07-22  0:42     ` Liang Yan [this message]

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=7bf462b9-6e79-d768-1e1a-8a1b78298cc9@suse.de \
    --to=lyan@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=cfontana@suse.de \
    --cc=cjia@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=dnigam@nvidia.com \
    --cc=kwankhede@nvidia.com \
    --cc=lushenming@huawei.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=targupta@nvidia.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.