Re: [RFC v4 PATCH 17/49] multi-process: Synchronize remote memory

[Stefan Hajnoczi]

On Thu, Oct 24, 2019 at 05:08:58AM -0400, Jagannathan Raman wrote:
> +static const TypeInfo remote_mem_sync_type_info = {
> +    .name          = TYPE_MEMORY_LISTENER,
> +    .parent        = TYPE_OBJECT,
> +    .instance_size = sizeof(RemoteMemSync),
> +};
> +
> +static void remote_mem_sync_register_types(void)
> +{
> +    type_register_static(&remote_mem_sync_type_info);
> +}
> +
> +type_init(remote_mem_sync_register_types)

Why is a QEMU Object necessary for the memory listener?  QEMU Objects
are used for the device model and -object.  The memory listener is an
internal concept that doesn't need to be exposed as a QEMU Object.  It's
fine to use plain C structs and functions, not everything needs to be a
QEMU Object.

> +/*
> + * TODO: Memory Sync need not be instantianted once per every proxy device.
> + *       All remote devices are going to get the exact same updates at the
> + *       same time. It therefore makes sense to have a broadcast model.
> + *
> + *       Broadcast model would involve running the MemorySync object in a
> + *       thread. MemorySync would contain a list of mpqemu-link objects
> + *       that need notification. proxy_ml_commit() could send the same
> + *       message to all the links at the same time.

Once mpqemu-link is made event-loop friendly (asynchronous) it won't be
necessary to create more threads.

signature.asc
Description: PGP signature