qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Zhao Yan <yan.y.zhao@intel.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH] vfio: assign idstr for VFIO's mmaped regions for migration
Date: Tue, 8 Jan 2019 10:09:11 -0700	[thread overview]
Message-ID: <20190108100911.6e089f8c@x1.home> (raw)
In-Reply-To: <20190108060348.3359-2-yan.y.zhao@intel.com>

On Tue,  8 Jan 2019 01:03:48 -0500
Zhao Yan <yan.y.zhao@intel.com> wrote:

> if multiple regions in vfio are mmaped, their corresponding ramblocks
> are like below, i.e. their idstrs are "".
> 
> (qemu) info ramblock
> Block Name  PSize       Offset               Used            Total
> pc.ram      4 KiB  0x0000000000000000 0x0000000020000000 0x0000000020000000
>             4 KiB  0x0000000021100000 0x0000000020000000 0x0000000020000000
>             4 KiB  0x0000000020900000 0x0000000000800000 0x0000000000800000
>             4 KiB  0x0000000020240000 0x0000000000687000 0x0000000000687000
>             4 KiB  0x00000000200c0000 0x0000000000178000 0x0000000000178000
> pc.bios     4 KiB  0x0000000020000000 0x0000000000040000 0x0000000000040000
> pc.rom      4 KiB  0x0000000020040000 0x0000000000020000 0x0000000000020000
> 
> This is because ramblocks' idstr are assigned by calling
> vmstate_register_ram(), but memory region of type ram device ptr does not
> call vmstate_register_ram().
> vfio_region_mmap
>         |->memory_region_init_ram_device_ptr
>                |-> memory_region_init_ram_ptr
> 
> Without empty idstrs will cause problem to snapshot copying during
> migration, because it uses ramblocks' idstr to identify ramblocks.
> ram_save_setup {
>   …
>   RAMBLOCK_FOREACH(block) {
>       qemu_put_byte(f, strlen(block->idstr));
>       qemu_put_buffer(f, (uint8_t *)block->idstr,strlen(block->idstr));
>       qemu_put_be64(f, block->used_length);
>   }
>   …
> }
> ram_load() {
>     block = qemu_ram_block_by_name(id);
>     if (block) {
>         if (length != block->used_length) {
>             qemu_ram_resize(block, length, &local_err);
>         }
>      ….
>    }
> }
> 
> Therefore, in this patch,
> vmstate_register_ram() is called for memory region of type ram ptr,
> also a unique vfioid is assigned to vfio devices across source
> and target vms.
> e.g. in source vm, use qemu parameter
> -device
> vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/
> 882cc4da-dede-11e7-9180-078a62063ab1,vfioid=igd
> 
> and in target vm, use qemu paramter
> -device
> vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/
> 5ac1fb20-2bbf-4842-bb7e-36c58c3be9cd,vfioid=igd

Why wouldn't we just use the id= (DeviceState.id) value instead of
adding yet another one?  I can't imagine anyone, especially libvirt,
wants to deal with a vfio specific id for a device.

> Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
> ---
>  hw/vfio/pci.c                 | 8 +++++++-
>  include/hw/vfio/vfio-common.h | 1 +
>  memory.c                      | 4 ++++
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index c0cb1ec289..7bc2ed0752 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2533,7 +2533,12 @@ static void vfio_populate_device(VFIOPCIDevice *vdev, Error **errp)
>      }
>  
>      for (i = VFIO_PCI_BAR0_REGION_INDEX; i < VFIO_PCI_ROM_REGION_INDEX; i++) {
> -        char *name = g_strdup_printf("%s BAR %d", vbasedev->name, i);
> +        char *name;
> +        if (vbasedev->vfioid) {
> +            name = g_strdup_printf("%s BAR %d", vbasedev->vfioid, i);
> +        } else {
> +            name = g_strdup_printf("%s BAR %d", vbasedev->name, i);
> +        }
>  
>          ret = vfio_region_setup(OBJECT(vdev), vbasedev,
>                                  &vdev->bars[i].region, i, name);
> @@ -3180,6 +3185,7 @@ static void vfio_instance_init(Object *obj)
>  static Property vfio_pci_dev_properties[] = {
>      DEFINE_PROP_PCI_HOST_DEVADDR("host", VFIOPCIDevice, host),
>      DEFINE_PROP_STRING("sysfsdev", VFIOPCIDevice, vbasedev.sysfsdev),
> +    DEFINE_PROP_STRING("vfioid", VFIOPCIDevice, vbasedev.vfioid),
>      DEFINE_PROP_ON_OFF_AUTO("display", VFIOPCIDevice,
>                              display, ON_OFF_AUTO_OFF),
>      DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice,
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index 1b434d02f6..84bab94f52 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -108,6 +108,7 @@ typedef struct VFIODevice {
>      struct VFIOGroup *group;
>      char *sysfsdev;
>      char *name;
> +    char *vfioid;
>      DeviceState *dev;
>      int fd;
>      int type;
> diff --git a/memory.c b/memory.c
> index d14c6dec1d..dbb29fa989 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1588,6 +1588,7 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
>                                  uint64_t size,
>                                  void *ptr)
>  {
> +    DeviceState *owner_dev;
>      memory_region_init(mr, owner, name, size);
>      mr->ram = true;
>      mr->terminates = true;
> @@ -1597,6 +1598,9 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
>      /* qemu_ram_alloc_from_ptr cannot fail with ptr != NULL.  */
>      assert(ptr != NULL);
>      mr->ram_block = qemu_ram_alloc_from_ptr(size, ptr, mr, &error_fatal);
> +
> +    owner_dev = DEVICE(owner);
> +    vmstate_register_ram(mr, owner_dev);

Where does the corresponding vmstate_unregister_ram() call occur when
unplugged?  Thanks,

Alex

>  }
>  
>  void memory_region_init_ram_device_ptr(MemoryRegion *mr,

  reply	other threads:[~2019-01-08 17:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-08  6:03 [Qemu-devel] [PATCH] vfio: assign idstr for VFIO's mmaped regions for migration Zhao Yan
2019-01-08  6:03 ` Zhao Yan
2019-01-08 17:09   ` Alex Williamson [this message]
2019-01-10  1:19     ` Zhao Yan
2019-02-20 11:17       ` Gonglei (Arei)

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=20190108100911.6e089f8c@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yan.y.zhao@intel.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).