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

[Paolo Bonzini <pbonzini@redhat.com>]

On 22/06/2017 12:38, Peter Maydell wrote:
> 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.)

I don't disagree, and if you found a way to fix all frontends at the
same time that would be great.

However, again this is not exclusive to character devices.  I mentioned
real-time clocks, and I don't see an easy way to fix that.

Paolo