All of lore.kernel.org
 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 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.