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. - Steve
