On Thu, Aug 14, 2025 at 11:28:24AM +0200, Eugenio Perez Martin wrote: > Well you need to send the vq addresses and properties to preheat > these. If the address is invalid, the destination device will > interpret the vq address as the avail ring, for example, and will read > an invalid avail idx.
I see now. But.. isn't vq addresses assigned by the guest driver? What happens if one pre-heated the vqs but VM rebooted right before live migration decides to switchover to dest QEMU? > > > For softwares, is it about memory transaction updates due to the vqueues? > > If so, have we investigated a more generic approach on memory side, likely > > some form of continuation from Chuang's work I previously mentioned? > > > > This work is very interesting, and most of the downtime was because of > memory pinning indeed. Thanks for bringing it up! But the downtime is > not caused for the individual vq memory config, but for pinning all > the guest's memory for the device to access to it. > > I think it is worth exploring if it affects the downtime in the case > of HW. I don't see any reason to reject that series but lack of > reviews, isn't it? Partly yes.. but not fully. I don't remember many details, but I do remember the series tried to mark the whole device load to be one memory transaction, which will cause the guest GPA flatview being obsolete during that period. The issue should be that some of the special devices will need to access guest memory during post_load(), hence one transaction wouldn't be enough, and I didn't remember whether we have captured all the outliers of such, or any side effects due to a possible obsolete flatview's presence. In one of the later discussions, Stefan used to mention we could provide a smaller transaction window and I think that might be something we can also try. For example, I think it's worthwhile to try one transaction per virtio-net device, then all the vqueues will be loaded in one transaction as long as the load of the virtio-net device doesn't need to access guest memory. -- Peter Xu
