Hi; I'm currently writing a UART device model, and I want to make it avoid using the deprecated qemu_chr_fe_write_all() (in the same way that the hw/char/cadence_uart.c code does, by using qemu_chr_fe_write() and then registering a callback with qemu_chr_fe_add_watch() if the write doesn't manage to send data).
I have some code that seems to work, but I'm not sure about how the chardev frontend callbacks interact with VM start, stop and migration. 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? 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? 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) ? 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?". 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? 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"... thanks -- PMM
