search for: stat_vq_elem

...like all you know is you got free page end. Could be any reason for this. > > > > > > I think this would be something that the current live migration lacks - what the > > > device read from the vq is not transferred during live migration, an example is the > > > stat_vq_elem: > > > Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c > > This does not touch guest memory though it just manipulates > > internal state to make it easier to migrate. > > It's transparent to guest as migration should be. > > &gt...

...like all you know is you got free page end. Could be any reason for this. > > > > > > I think this would be something that the current live migration lacks - what the > > > device read from the vq is not transferred during live migration, an example is the > > > stat_vq_elem: > > > Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c > > This does not touch guest memory though it just manipulates > > internal state to make it easier to migrate. > > It's transparent to guest as migration should be. > > &gt...

...gt; Looks like all you know is you got free page end. Could be any reason for this. >>>> I think this would be something that the current live migration lacks - what the >>>> device read from the vq is not transferred during live migration, an example is the >>>> stat_vq_elem: >>>> Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c >>> This does not touch guest memory though it just manipulates >>> internal state to make it easier to migrate. >>> It's transparent to guest as migration should be. &gt...

...migration even? > > Looks like all you know is you got free page end. Could be any reason for this. > > > I think this would be something that the current live migration lacks - what the > device read from the vq is not transferred during live migration, an example is the > stat_vq_elem: > Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c This does not touch guest memory though it just manipulates internal state to make it easier to migrate. It's transparent to guest as migration should be. > For all the things that are added to the vq an...

...migration even? > > Looks like all you know is you got free page end. Could be any reason for this. > > > I think this would be something that the current live migration lacks - what the > device read from the vq is not transferred during live migration, an example is the > stat_vq_elem: > Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c This does not touch guest memory though it just manipulates internal state to make it easier to migrate. It's transparent to guest as migration should be. > For all the things that are added to the vq an...

...even? >>> Looks like all you know is you got free page end. Could be any reason for this. >> >> I think this would be something that the current live migration lacks - what the >> device read from the vq is not transferred during live migration, an example is the >> stat_vq_elem: >> Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c > This does not touch guest memory though it just manipulates > internal state to make it easier to migrate. > It's transparent to guest as migration should be. > >> For all the things th...

...a? And how do you know this is migration even? > Looks like all you know is you got free page end. Could be any reason for this. I think this would be something that the current live migration lacks - what the device read from the vq is not transferred during live migration, an example is the stat_vq_elem: Line 476 at https://github.com/qemu/qemu/blob/master/hw/virtio/virtio-balloon.c For all the things that are added to the vq and need to be held by the device to use later need to consider the situation that live migration might happen at any time and they need to be re-taken from the vq by the d...

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > Add a new vq, ctrl_vq, to handle commands between the host and guest. > With this feature, we will be able to have the control plane and data > plane separated. In other words, the control related commands of each > feature will be sent via the ctrl_vq, meanwhile each feature may have > its own vq used as a data plane. >

On Sat, Sep 30, 2017 at 12:05:54PM +0800, Wei Wang wrote: > Add a new vq, ctrl_vq, to handle commands between the host and guest. > With this feature, we will be able to have the control plane and data > plane separated. In other words, the control related commands of each > feature will be sent via the ctrl_vq, meanwhile each feature may have > its own vq used as a data plane. >