search for: stats_vq_elem

add modern header. This patch is for virtio 1.0 branch, doesn't apply to master. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/hw/virtio/virtio-balloon.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h index f863bfe..79eca67 100644 --- a/include/hw/virtio/virtio-balloon.h +++

add modern header. This patch is for virtio 1.0 branch, doesn't apply to master. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/hw/virtio/virtio-balloon.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h index f863bfe..79eca67 100644 --- a/include/hw/virtio/virtio-balloon.h +++

...e..568a008 100644 > --- a/hw/virtio/virtio-balloon.c > +++ b/hw/virtio/virtio-balloon.c > @@ -239,7 +239,8 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) > { > VirtIOBalloon *s = VIRTIO_BALLOON(vdev); > VirtQueueElement *elem = &s->stats_vq_elem; > - VirtIOBalloonStat stat; > + VirtIOBalloonStat legacy_stat; > + VirtIOBalloonStatModern modern_stat; > size_t offset = 0; > qemu_timeval tv; > > @@ -253,14 +254,28 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) >...

...e..568a008 100644 > --- a/hw/virtio/virtio-balloon.c > +++ b/hw/virtio/virtio-balloon.c > @@ -239,7 +239,8 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) > { > VirtIOBalloon *s = VIRTIO_BALLOON(vdev); > VirtQueueElement *elem = &s->stats_vq_elem; > - VirtIOBalloonStat stat; > + VirtIOBalloonStat legacy_stat; > + VirtIOBalloonStatModern modern_stat; > size_t offset = 0; > qemu_timeval tv; > > @@ -253,14 +254,28 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) >...

...ation should pass enough data source to destination for > > destination to continue where source left off without guest help. > > > > I'm afraid it would be difficult to pass the entire VirtQueueElement to the > destination. I think > that would also be the reason that stats_vq_elem chose to rewind from the > guest vq, which re-do the > virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to > the guest physical > address relationship may be changed on the destination). Yes but note how that rewind does not involve modifying the ring. It jus...

...ation should pass enough data source to destination for > > destination to continue where source left off without guest help. > > > > I'm afraid it would be difficult to pass the entire VirtQueueElement to the > destination. I think > that would also be the reason that stats_vq_elem chose to rewind from the > guest vq, which re-do the > virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to > the guest physical > address relationship may be changed on the destination). Yes but note how that rewind does not involve modifying the ring. It jus...

...d pass enough data source to destination for >>> destination to continue where source left off without guest help. >>> >> I'm afraid it would be difficult to pass the entire VirtQueueElement to the >> destination. I think >> that would also be the reason that stats_vq_elem chose to rewind from the >> guest vq, which re-do the >> virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to >> the guest physical >> address relationship may be changed on the destination). > Yes but note how that rewind does not involve modify...

.../virtio-balloon.c index d2d7c3e..568a008 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -239,7 +239,8 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) { VirtIOBalloon *s = VIRTIO_BALLOON(vdev); VirtQueueElement *elem = &s->stats_vq_elem; - VirtIOBalloonStat stat; + VirtIOBalloonStat legacy_stat; + VirtIOBalloonStatModern modern_stat; size_t offset = 0; qemu_timeval tv; @@ -253,14 +254,28 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) */ reset_stats(s); - while (i...

...- a/hw/virtio/virtio-balloon.c > > +++ b/hw/virtio/virtio-balloon.c > > @@ -239,7 +239,8 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq) > > { > > VirtIOBalloon *s = VIRTIO_BALLOON(vdev); > > VirtQueueElement *elem = &s->stats_vq_elem; > > - VirtIOBalloonStat stat; > > + VirtIOBalloonStat legacy_stat; > > + VirtIOBalloonStatModern modern_stat; > > size_t offset = 0; > > qemu_timeval tv; > > > > @@ -253,14 +254,28 @@ static void virtio_balloon_receive_stats(VirtIODevic...

...her suggestions. > IMO migration should pass enough data source to destination for > destination to continue where source left off without guest help. > I'm afraid it would be difficult to pass the entire VirtQueueElement to the destination. I think that would also be the reason that stats_vq_elem chose to rewind from the guest vq, which re-do the virtqueue_pop() --> virtqueue_map_desc() steps (the QEMU virtual address to the guest physical address relationship may be changed on the destination). How about another direction which would be easier - using two 32-bit device specific con...

On Mon, Oct 02, 2017 at 04:38:01PM +0000, Wang, Wei W wrote: > On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > > > +static void ctrlq_send_cmd(struct virtio_balloon *vb, > > > + struct virtio_balloon_ctrlq_cmd *cmd, > > > + bool inbuf) > > > +{ > > > + struct

On Mon, Oct 02, 2017 at 04:38:01PM +0000, Wang, Wei W wrote: > On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: > > On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > > > +static void ctrlq_send_cmd(struct virtio_balloon *vb, > > > + struct virtio_balloon_ctrlq_cmd *cmd, > > > + bool inbuf) > > > +{ > > > + struct

...dern { > > typedef struct VirtIOBalloon { > VirtIODevice parent_obj; > - VirtQueue *ivq, *dvq, *svq; > + VirtQueue *ivq, *dvq, *svq, *fvq; > uint32_t num_pages; > uint32_t actual; > uint64_t stats[VIRTIO_BALLOON_S_NR]; > VirtQueueElement *stats_vq_elem; > + VirtQueueElement *free_pages_vq_elem; > size_t stats_vq_offset; > QEMUTimer *stats_timer; > int64_t stats_last_update; > int64_t stats_poll_interval; > uint32_t host_features; > + uint64_t *free_pages_bitmap; > + uint64_t free_pages_cou...

...3,21 @@ typedef struct virtio_balloon_stat_modern { typedef struct VirtIOBalloon { VirtIODevice parent_obj; - VirtQueue *ivq, *dvq, *svq; + VirtQueue *ivq, *dvq, *svq, *fvq; uint32_t num_pages; uint32_t actual; uint64_t stats[VIRTIO_BALLOON_S_NR]; VirtQueueElement *stats_vq_elem; + VirtQueueElement *free_pages_vq_elem; size_t stats_vq_offset; QEMUTimer *stats_timer; int64_t stats_last_update; int64_t stats_poll_interval; uint32_t host_features; + uint64_t *free_pages_bitmap; + uint64_t free_pages_count; + MemLayout mem_layout; + VIRT...

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