[PATCH 06/18] virtio: decrement last_avail_idx with inuse before saving.

2011-04-25 Thread OHMURA Kei
From: Yoshiaki Tamura For regular migration inuse == 0 always as requests are flushed before save. However, event-tap log when enabled introduces an extra queue for requests which is not being flushed, thus the last inuse requests are left in the event-tap queue. Move the last_avail_idx value se

[PATCH 06/18] virtio: decrement last_avail_idx with inuse before saving.

2011-03-22 Thread Yoshiaki Tamura
For regular migration inuse == 0 always as requests are flushed before save. However, event-tap log when enabled introduces an extra queue for requests which is not being flushed, thus the last inuse requests are left in the event-tap queue. Move the last_avail_idx value sent to the remote back to

[PATCH 06/18] virtio: decrement last_avail_idx with inuse before saving.

2011-02-23 Thread Yoshiaki Tamura
For regular migration inuse == 0 always as requests are flushed before save. However, event-tap log when enabled introduces an extra queue for requests which is not being flushed, thus the last inuse requests are left in the event-tap queue. Move the last_avail_idx value sent to the remote back to

[PATCH 06/18] virtio: decrement last_avail_idx with inuse before saving.

2011-02-23 Thread Yoshiaki Tamura
For regular migration inuse == 0 always as requests are flushed before save. However, event-tap log when enabled introduces an extra queue for requests which is not being flushed, thus the last inuse requests are left in the event-tap queue. Move the last_avail_idx value sent to the remote back to

[PATCH 06/18] virtio: decrement last_avail_idx with inuse before saving.

2011-02-10 Thread Yoshiaki Tamura
For regular migration inuse == 0 always as requests are flushed before save. However, event-tap log when enabled introduces an extra queue for requests which is not being flushed, thus the last inuse requests are left in the event-tap queue. Move the last_avail_idx value sent to the remote back to