search for: dvq

...n_handle_output(VirtIODevice *vdev, VirtQueue *vq) > balloon_inflate_page(s, section.mr, > section.offset_within_region, > psize, &pbp); > - } else if (vq == s->dvq) { > - balloon_deflate_page(s, section.mr, section.offset_within_region); > + } else if (vq == s->dvq || vq == s->dcvq) { > + balloon_deflate_page(s, section.mr, section.offset_within_region, > +...

...if (ret < 0) { > error_setg(errp, "Only one balloon device is supported"); > @@ -440,6 +518,7 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp) > s->ivq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output); > s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output); > s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats); > + s->fvq = virtio_add_queue(vdev, 128, virtio_balloon_get_free_pages); > > reset_stats(s); > > diff --git a/include/hw/virtio...

...pa); > - if (!qemu_balloon_is_inhibited()) { > - if (vq == s->ivq) { > - balloon_inflate_page(s, section.mr, > - section.offset_within_region, &pbp); > - } else if (vq == s->dvq) { > - balloon_deflate_page(s, section.mr, section.offset_within_region); > - } else { > - g_assert_not_reached(); > + trace_virtio_balloon_handle_output(memory_region_name(section.mr), > +...

..._free_pages, s); if (ret < 0) { error_setg(errp, "Only one balloon device is supported"); @@ -440,6 +518,7 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp) s->ivq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output); s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output); s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats); + s->fvq = virtio_add_queue(vdev, 128, virtio_balloon_get_free_pages); reset_stats(s); diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw...

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles

The current QEMU live migration implementation mark the all the guest's RAM pages as dirtied in the ram bulk stage, all these pages will be processed and that takes quit a lot of CPU cycles. >From guest's point of view, it doesn't care about the content in free pages. We can make use of this fact and skip processing the free pages in the ram bulk stage, it can save a lot CPU cycles

..._region_get_ram_ptr is bending the rules a bit, but > should be OK because we only want a single page. */ > addr = section.offset_within_region; > balloon_page(memory_region_get_ram_ptr(section.mr) + addr, > !!(vq == s->dvq)); > memory_region_unref(section.mr); > } > > so all that happens when we get a page is balloon_page. > and > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled()...

..._region_get_ram_ptr is bending the rules a bit, but > should be OK because we only want a single page. */ > addr = section.offset_within_region; > balloon_page(memory_region_get_ram_ptr(section.mr) + addr, > !!(vq == s->dvq)); > memory_region_unref(section.mr); > } > > so all that happens when we get a page is balloon_page. > and > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > if (!qemu_balloon_is_inhibited() && (!kvm_enabled()...

.../* Using memory_region_get_ram_ptr is bending the rules a bit, but should be OK because we only want a single page. */ addr = section.offset_within_region; balloon_page(memory_region_get_ram_ptr(section.mr) + addr, !!(vq == s->dvq)); memory_region_unref(section.mr); } so all that happens when we get a page is balloon_page. and static void balloon_page(void *addr, int deflate) { #if defined(__linux__) if (!qemu_balloon_is_inhibited() && (!kvm_enabled() ||...

> Subject: Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration > optimization > > On Fri, Mar 04, 2016 at 09:08:44AM +0000, Li, Liang Z wrote: > > > On Fri, Mar 04, 2016 at 01:52:53AM +0000, Li, Liang Z wrote: > > > > > I wonder if it would be possible to avoid the kernel changes > > > > > by parsing /proc/self/pagemap - if that

> Subject: Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration > optimization > > On Fri, Mar 04, 2016 at 09:08:44AM +0000, Li, Liang Z wrote: > > > On Fri, Mar 04, 2016 at 01:52:53AM +0000, Li, Liang Z wrote: > > > > > I wonder if it would be possible to avoid the kernel changes > > > > > by parsing /proc/self/pagemap - if that

...is bending the rules a bit, but > > should be OK because we only want a single page. */ > > addr = section.offset_within_region; > > balloon_page(memory_region_get_ram_ptr(section.mr) + addr, > > !!(vq == s->dvq)); > > memory_region_unref(section.mr); > > } > > > > so all that happens when we get a page is balloon_page. > > and > > > > static void balloon_page(void *addr, int deflate) { #if defined(__linux__) > > if (!qemu_balloon_is...

...alloonStat { uint64_t val; } QEMU_PACKED VirtIOBalloonStat; +typedef struct virtio_balloon_stat_modern { + uint16_t tag; + uint8_t reserved[6]; + uint64_t val; +} VirtIOBalloonStatModern; + typedef struct VirtIOBalloon { VirtIODevice parent_obj; VirtQueue *ivq, *dvq, *svq; -- MST

...alloonStat { uint64_t val; } QEMU_PACKED VirtIOBalloonStat; +typedef struct virtio_balloon_stat_modern { + uint16_t tag; + uint8_t reserved[6]; + uint64_t val; +} VirtIOBalloonStatModern; + typedef struct VirtIOBalloon { VirtIODevice parent_obj; VirtQueue *ivq, *dvq, *svq; -- MST

...ft intact across virtio device reset. Leverage the .reset_map callback to reset memory mapping, then the device .reset routine can run free from having to clean up memory mappings. Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> --- RFC v1 -> v2: - fix error path when both CVQ and DVQ fall in same asid --- drivers/vdpa/mlx5/core/mlx5_vdpa.h | 1 + drivers/vdpa/mlx5/core/mr.c | 70 +++++++++++++++++++++++--------------- drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 +++++++--- 3 files changed, 56 insertions(+), 33 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mlx5_vdpa.h b...

This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix

This patch series is based on Eugenio's fix for handling CVQs in a different ASID [0]. The first patch is the actual fix. The next 2 patches are fixing a possible issue that I found while implementing patch 1. The patches are ordered like this for clarity. [0] https://lore.kernel.org/lkml/20230112142218.725622-1-eperezma at redhat.com/ Dragos Tatulea (1): vdpa/mlx5: Fix

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

In order to reduce needlessly high setup and teardown cost of iotlb mapping during live migration, it's crucial to decouple the vhost-vdpa iotlb abstraction from the virtio device life cycle, i.e. iotlb mappings should be left intact across virtio device reset [1]. For it to work, the on-chip IOMMU parent device should implement a separate .reset_map() operation callback to restore 1:1 DMA

...cnJ3$(VwZ39!;o8CP?UPh<jsMYP|0OP>otUV zl(FW*6_B4I8>uEG;j3P5vJP5wmp?2mlMvFCwr2E`+icu)#_NJCoolluDWKDALtGYS zMCxmO{e1zSkfXdS%S+bDuyq#6vb8oYuQg8o|8qC|VWEQ;(KGzvI|M~0<O#NgU0tL6 zZmBhv7;;Ug?4kvj63-NF(kKraPLhbd&qRXK(-e{kXV}t<R at W*~^o at 41h0W7wZj+b| ziR)0a`2NJcTAMu^a<SC&enm|>8DVQC!#Rx(yi>L$C4D7MOG>wkud^7NfbjdS at 7%FV zV}<jpqu(t(Nt=CcTo(L?iuy+AzBped&1^TC+2%L<5#w{mSK^LuiJ2|A!m$FD%{LS2 z$t~nJe)}b|gokLa8tiGdpxtqGhci6M=07czbY${ewBTCA+HB;TKKGd$KsJs!GOsik z(^CWImrw|XCY)+nFUuhEN;6E2>04nW63RCHxI{%ykvx5^n$qo&mG~;9XJHM{>^_r+ zlW>#7vygQnj&ARb=4RWHNVrXk...