On Sun, 11 Sept 2022 at 18:14, Arwed Meyer <arwed.me...@gmx.de> wrote: > > Am 08.09.22 um 23:11 schrieb Peter Maydell: > > On Thu, 8 Sept 2022 at 18:43, Arwed Meyer <arwed.me...@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.me...@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
