Re: Save qemu state
On Wed, 1 Dec 2021 at 19:28, Leek, Jim wrote: > So, why doesn't QEMU support external checkpoints? (ie an option > where checkpoints each get written to a new file.) If you really want to save to an external file I think you can do this by treating it as a migration (which is the same infrastructure underneath for snapshotting the machine state, but it sends it over eg a file descriptor or a socket rather than saving it into a qcow2 file). David Gilbert gives a set of commands that might work for this in this email thread: https://lore.kernel.org/qemu-devel/YRvjHiZmPkSuv%2F%2Fz@work-vm/ # (qemu) migrate_set_parameter max-bandwidth 100G # (qemu) migrate "exec:cat > myfile.mig" # (qemu) q # # qemu -incoming "exec:cat myfile.mig" I haven't tried them, but this sort of thing is probably a good place to start if you want to investigate more complicated things than "just save to the qcow2". My guess at the reason why savevm requires qcow2 is because qcow2 provides a builtin mechanism for taking a low-cost snapshot of the state of the disk image -- otherwise you would end up needing to put the whole of your raw disk image contents in the snapshot, or otherwise manually arrange to do something to keep a copy of them. So it probably didn't seem like a big deal to tie the vm save/restore to qcow2 back when that code was written. (Looking into the depths of the git history it looks like the very first incarnation of 'savevm' really did take a separate filename to write the state to. Commit faea38e78 in 2006 is when that changed.) These days, the migrate command provides the power and flexibility that is needed by the main use-case of the ability to checkpoint the VM, ie migrating the VM from one host to another. The use as a developer-tool convenience is something we get as a handy side-benefit, not something anybody's actively paid to improve the ergonomics of. -- PMM
RE: Save qemu state
So, why doesn't QEMU support external checkpoints? (ie an option where checkpoints each get written to a new file.) -Original Message- From: Qemu-discuss On Behalf Of Peter Maydell Sent: Wednesday, December 1, 2021 9:11 AM To: Динар Талибуллин Cc: qemu-discuss@nongnu.org Subject: Re: Save qemu state On Wed, 1 Dec 2021 at 14:14, Динар Талибуллин wrote: > > Hello. Is it possible to save qemu state if image is in *. elf format? > I tried to do it in qemu monitor, but it require qcow2 format You need QEMU to know about one disk which is in qcow2 format, so it can save the state there, but that disk doesn't actually have to be attached to the emulated machine. This blog post has a note on how to do that: https://urldefense.us/v3/__https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/__;!!G2kpM7uM-TzIFchu!m3xbK4CoKKh7PSXBOyAvLwSMVOMcUtGC2p2XsSROlweyhgOgW7Y9Eigo-wp7yaw$ (look for the bit starting "If the QEMU system you’re trying to debug doesn’t have a disk image at all".) -- PMM
Re: Save qemu state
On Wed, 1 Dec 2021 at 14:14, Динар Талибуллин wrote: > > Hello. Is it possible to save qemu state if image is in *. elf format? > I tried to do it in qemu monitor, but it require qcow2 format You need QEMU to know about one disk which is in qcow2 format, so it can save the state there, but that disk doesn't actually have to be attached to the emulated machine. This blog post has a note on how to do that: https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/ (look for the bit starting "If the QEMU system you’re trying to debug doesn’t have a disk image at all".) -- PMM
Save qemu state
Hello. Is it possible to save qemu state if image is in *. elf format?I tried to do it in qemu monitor, but it require qcow2 format
Re: DeviceState definition
On Tue, 30 Nov 2021 at 22:53, abhijeet inamdar wrote: > What difference does it make to define: > > DeviceState *nvic; > > nvic = qdev_create(NULL, TYPE_ARMV7M); This creates a new device in freshly allocated memory, both initializing and realizing it, and returns a pointer to that newly created device. > vs > > DeviceState *armv7m; > > armv7m = DEVICE(>armv7m); This is not creating anything. It's just a cast -- it is exactly like "armv7m = (DeviceState*)(>armv7m);" except that it does a runtime typecheck that the pointer really is pointing to an initialized object of the right type. Unless the field s->armv7m has been previously correctly initialized, the typechecked cast will assert at runtime. > Can you please explain me because I'm confused between two machines > which I want to adapt for my custom machine which is based on > Cortex-M3. I think what you're looking at is that there are two ways of creating devices: * call functions that allocate memory, initialize a device in that memory, and return you a pointer; your device or machine state struct has fields which are "Foo *foo". * use "in-place" initialization, where the device or machine state struct has fields which are "Foo foo", and then you call functions which initialize that field. Mostly new QEMU code uses the second strategy, but there's still a fair bit of code that does the first. You should prefer the second, I think. -- PMM
