Re: [Qemu-devel] qemu_chr_fe_add_watch interaction with VM start/stop/migrate

[Paolo Bonzini <pbonzini@redhat.com>]

On 22/06/2017 12:09, Peter Maydell wrote:
> For instance, suppose my UART tries to write to the chardev but
> can't, so it registers a callback with qemu_chr_fe_add_watch().
> Then the user stops the VM. Does the chardev UI guarantee that
> my callback won't get called until the user restarts the VM,
> or does my callback function have to do something to say "don't
> actually update the emulation state if we're stopped"?
> If the user then restarts the VM, do I need to do something to
> retry the chardev write?

Currently, chardev code runs normally between stop and start.

> For migration, if we're migrating in the state where I have a
> pending character I'd like to write to the chardev, what do I need
> to do on the destination side? Do I need to call qemu_chr_fe_add_watch
> in the post-load function, or is this too early and I need to do
> something to call it when the destination VM is actually restarted?

Post-load is fine.  There could be interesting interactions with
interrupts, but these are not specific to character device backends
(real-time clocks are another example).  So boards should create
interrupt controllers and distributors as soon as possible.

On the save side, when migration is about to finish, the mig thread
takes the I/O thread lock, so chardevs cannot run anymore at that point.

> More generally, am I guaranteed that my qemu_chr_fe_add_watch()
> callbacks are only called with the iothread mutex held (ie that
> I don't need to worry about races between device model functions
> called from the guest and the callbacks) ?

Yes.  Chardev backends can be written to outside the iothread mutex, but
callbacks are always protected by the iothread mutex unless mentioned
specifically by the documentation and even then, only if you run in your
own IOThread.

> There are I think similar questions about the read handler and event
> handler functions that every UART model registers with the
> qemu_chr_fe_set_handlers function: are those only called when the
> VM is actually running, or is special casing required for "called
> when the VM is stopped?".

No special casing is currently done by the other backends.  It seems to
work fine in practice...

> And one that I think is true but we don't document: is it the case
> that the chardev layer guarantees not to call the chardev's IOReadHandler
> unless its IOCanReadHandler has returned OK?

Yes, and no more bytes than the can_read handler has told him to return.

Paolo

> These all seem like things it would be nice to have documented in
> include/chardev/char-fe.h :-)  What I would like the answer to be
> (as far as is possible) is "the chardev layer handles these issues
> so the frontends don't need to"...