Re: [PATCH V2 01/11] machine: alloc-anon option

[Steven Sistare]

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