Re: [PATCH v2 1/5] msmouse: Handle mouse reset

[Peter Maydell]

On Sun, 11 Sept 2022 at 18:14, Arwed Meyer <arwed.meyer@gmx.de> wrote:
>
> Am 08.09.22 um 23:11 schrieb Peter Maydell:
> > On Thu, 8 Sept 2022 at 18:43, Arwed Meyer <arwed.meyer@gmx.de> wrote:
> >>
> >> Detect mouse reset via RTS or DTR line:
> >> Don't send or process anything while in reset.
> >> When coming out of reset, send ID sequence first thing.
> >> This allows msmouse to be detected by common mouse drivers.
> >>
> >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/77
> >> Signed-off-by: Arwed Meyer <arwed.meyer@gmx.de>
> >
> > How does this work across migration? There doesn't seem
> > to be anything that handles migration of the existing
> > state inside the MouseChardev either, though...

> can you please explain in more detail what you don't understand and what
> you mean by "migration"?

Migration is when the state of the whole VM is copied from
one host to another, or, equivalently, when it is saved to
the disk image with 'savevm' to be restarted later. For this
to work all the guest-changeable state in the whole VM (all
device registers, internal state, etc) has to be saved so
it can be reloaded on the destination. My question is basically
how this new state in mouse->tiocm, and more generally how
the existing other state fields in that struct, are saved
and loaded during the migration process. I know how this
works for device models, but I'm not sure how chardevs
figure into it. (Perhaps the answer is "this shouldn't be
a chardev at all" ???)

thanks
-- PMM