On 07/05/2017 06:09 PM, Paolo Bonzini wrote:
On 05/07/2017 16:01, Anton Nefedov wrote:
This patch adds a possibility to change a char device without a frontend
removal.
1. Ideally, it would have to happen transparently to a frontend, i.e.
frontend would continue its regular operation.
However, backends are not stateless and are set up by the frontends
via qemu_chr_fe_<> functions, and it's not (generally) possible to replay
that setup entirely in a backend code, as different chardevs respond
to the setup calls differently, so do frontends work differently basing
on those setup responses.
Moreover, some frontend can generally get and save the backend pointer
(qemu_chr_fe_get_driver()), and it will become invalid after backend change.
So, a frontend which would like to support chardev hotswap has to register
a "backend change" handler, and redo its backend setup there.
2. Write path can be used by multiple threads and thus protected with
chr_write_lock.
So hotswap also has to be protected so write functions won't access
a backend being replaced.
Does this matter in practice? CharBackend thread safety can be left to
the front-end.
Paolo
Hi Paolo,
So instead we'll need to use proper locks in each of the front-ends?
Or do you mean that it can be skipped for the most of them? I don't know
about all possible threading cases.
e.g. for serial/virtio-serial? Will they always share the same thread
with hmp/qmp driven chardev-change command? And won't yield and hotswap
in the middle of some write handler?
/Anton
