qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] qemu_chr_fe_add_watch interaction with VM start/stop/migrat


From: Peter Maydell
Subject: [Qemu-devel] qemu_chr_fe_add_watch interaction with VM start/stop/migrate
Date: Thu, 22 Jun 2017 11:09:16 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]