On Thu, Jul 18, 2024 at 11:43:54AM -0400, Steven Sistare wrote: > On 7/17/2024 3:24 PM, Peter Xu wrote: > [...] > > > > PS to Steve: and I think I left tons of other comments in previous version > > outside this patch too, but I don't think they're fully discussed when this > > series was sent. I can re-read the series again, but I don't think it'll > > work out if we keep skipping discussions.. > > Hi Peter, let me address this part first, because I don't want you to think > that I ignored your questions and concerns. This V2 series tries to address > them. The change log was intended to be my response, rather than responding > to each open question individually, but let me try again here with more > detail. > I apologize if I don't summarize your concerns correctly or completely. > > issue: discomfort with exec. why is it needed? > response: exec is just a transport mechanism to send fd's to new qemu. > I refactored to separate core patches from exec-specific patches, submitted > cpr-transfer patches to illustrate a non-exec method, and provided reasons > why one vs the other would be desirable in the commit messages and cover > letter. > > issue: why do we need to preserve the ramblock fields and make them available > prior to object creation? > response. we don't need to preserve all of them, and we only need fd prior > to object creation, so I deleted the precreate, factory, and named object > patches, and added CprState to preserve fd's. used_length arrives in the > normal migration stream. max_length is recovered from the mfd using lseek. > > issue: the series is too large, with too much change. > response: in addition to the deletions mentioned above, I simplified the > functionality and tossed out style patches and nice-to-haves, so we can > focus on core functionality. V2 is much smaller. > > issue: memfd_create option is oddly expressed and hard to understand. > response: I redefined the option, deleted all the stylistic ramblock patches > to lay its workings bare, and explicitly documented its affect on all types > of memory in the commit messages and qapi documentation. > > issue: no need to preserve blocks like ROM for DMA (with memfd_create). > Blocks that must be preserved should be surfaced to the user as objects. > response: I disagree, and will continue that conversation in this email > thread. > > issue: how will vfio be handled? > response: I submitted the vfio patches (non-trivial, because first I had to > rework them without using precreate vmstate). > > issue: how will fd's be preserved for chardevs? > response: via cpr_save_fd, CprState, and cpr_load_fd at device creation time, > in each device's creation function, just like vfio. Those primitives are > defined in this V2 series.
Thanks for the answers. I think I'll need to read more into the patches in the next few days; it looks like I'll get more answers from there. I just sent an email probably when you're drafting this one.. it may has some questions that may not be covered here. I think a major issue with exec() is the (1-3) steps that I mentioned there that needs to run sequentially, and IIUC all these steps can be completely avoided in cpr-transfer, and it may matter a lot in huge VMs. But maybe I missed something. Please have a look there. -- Peter Xu
