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

[Peter Maydell <peter.maydell@linaro.org>]

On 22 June 2017 at 11:31, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> 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.

I think that's rather counterintuitive -- as a user, if I've
stopped the VM I don't expect any of its device state to change.
Stopped should mean "simulation state doesn't change".

>> 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.

This sounds wrong to me -- nobody should be asserting an
interrupt line during post-load, in the same way that nobody
should assert an interrupt line during reset. We don't have
any guarantees that the device on the other end of the line
has finished migration yet. I think we really need the
chardev backends to not start doing things until load has
finished and the VM has been restarted. (If we make "VM
stopped" mean "no chardev callbacks" then this would fall
out in the wash, though, since the callback registered in
post-load would only trigger on the following VM start.)

thanks
-- PMM