bwlp/qemu.git/qapi-schema-guest.json, branch spice_video_codecs

qemu-ga: move qemu-ga files to qga/

2012-12-19T07:31:30+00:00

Signed-off-by: Paolo Bonzini

qapi: Fix enumeration typo error

2012-09-14T07:21:29+00:00

Signed-off-by: Lei Li Reviewed-by: Luiz Capitulino Signed-off-by: Stefan Hajnoczi

qemu-ga: add guest-fstrim command

2012-06-21T22:59:27+00:00

FITRIM is a mounted filesystem feature to discard (or "trim") blocks which are not in use by the filesystem. This is useful for solid-state drives (SSDs) and thinly-provisioned storage. Provide access to the feature from the host so that filesystems can be trimmed periodically or before migration. Here is an example using scsi_debug: # modprobe scsi_debug lbpu=1 lbpws=1 # sg_vpd -p0xb2 /dev/sdb Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBWS): 1 Write same (10) with unmap bit supported (LBWS10): 0 # mke2fs /dev/sdb # cat /sys/bus/pseudo/drivers/scsi_debug/map 1-616,16257-16383 # mount /dev/sdb /run/media/pbonzini/test # dd if=/dev/zero of=/run/media/pbonzini/test/file # cat map 1-616,645-1588,1599-4026,4029-16383 # rm /run/media/pbonzini/test/file # ./qemu-ga /dev/fd/0 {"execute":"guest-fstrim"} {"return": {}} # cat map 1-612 Signed-off-by: Paolo Bonzini Reviewed-by: Luiz Capitulino Reviewed-by: Michal Privoznik Signed-off-by: Michael Roth

qemu-ga: guest-shutdown: use only async-signal-safe functions

2012-05-15T14:15:16+00:00

POSIX mandates[1] that a child process of a multi-thread program uses only async-signal-safe functions before exec(). We consider qemu-ga to be multi-thread, because it uses glib. However, qmp_guest_shutdown() uses functions that are not async-signal-safe. Fix it the following way: - fclose() -> reopen_fd_to_null() - execl() -> execle() - exit() -> _exit() - drop slog() usage (which is not safe) [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html Signed-off-by: Luiz Capitulino Reviewed-by: Eric Blake Signed-off-by: Michael Roth

qemu-ga: guest-suspend-hybrid: don't emit a success response

2012-05-15T14:15:16+00:00

Today, qemu-ga may not be able to emit a success response when guest-suspend-hybrid completes. This happens because the VM may suspend before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-hybrid to never emit a success response and suggests in the documentation what clients should do to check for success. Signed-off-by: Luiz Capitulino Signed-off-by: Michael Roth

qemu-ga: guest-suspend-ram: don't emit a success response

2012-05-15T14:15:16+00:00

Today, qemu-ga may not be able to emit a success response when guest-suspend-ram completes. This happens because the VM may suspend before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-ram to never emit a success response and suggests in the documentation what clients should do to check for success. Signed-off-by: Luiz Capitulino Signed-off-by: Michael Roth

qemu-ga: guest-suspend-disk: don't emit a success response

2012-05-15T14:15:16+00:00

Today, qemu-ga may not be able to emit a success response when guest-suspend-disk completes. This happens because the VM may vanish before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-suspend-disk to never emit a success response and suggests in the documentation what clients could do to check for success. Signed-off-by: Luiz Capitulino Signed-off-by: Michael Roth

qemu-ga: guest-shutdown: don't emit a success response

2012-05-15T14:15:16+00:00

Today, qemu-ga may not be able to emit a success response when guest-shutdown completes. This happens because the VM may vanish before qemu-ga is able to emit a response. This semantic is a bit confusing, as it's not clear for clients if they should wait for a response or how they should check for success. This commit solves that problem by changing guest-shutdown to never emit a success response and suggests in the documentation what clients could do to check for success. Signed-off-by: Luiz Capitulino Signed-off-by: Michael Roth

fix some common typos

2012-05-14T05:27:24+00:00

These were identified using: http://github.com/lyda/misspell-check and run like this to create a bourne shell script using GNU sed's -i option: git ls-files|grep -vF .bin | misspellings -f - |grep -v '^ERROR:' |perl \ -pe 's/^(.*?)\[(\d+)\]: (\w+) -> "(.*?)"$/sed -i '\''${2}s!$3!$4!'\'' $1/' Manually eliding the FP, "rela->real" and resolving "addres" to address (not "adders") we get this: sed -i '450s!thru!through!' Changelog sed -i '260s!neccessary!necessary!' coroutine-sigaltstack.c sed -i '54s!miniscule!minuscule!' disas.c sed -i '1094s!thru!through!' hw/usb/hcd-ehci.c sed -i '1095s!thru!through!' hw/usb/hcd-ehci.c sed -i '21s!unecessary!unnecessary!' qapi-schema-guest.json sed -i '307s!explictly!explicitly!' qemu-ga.c sed -i '490s!preceeding!preceding!' qga/commands-posix.c sed -i '792s!addres!address!' qga/commands-posix.c sed -i '6s!beeing!being!' tests/tcg/test-mmap.c Also, manually fix "arithmentic", spotted by Peter Maydell: sed -i 's!arithmentic!arithmetic!' coroutine-sigaltstack.c Signed-off-by: Jim Meyering Reviewed-by: Peter Maydell

qemu-ga: persist tracking of fsfreeze state via filesystem

2012-04-30T13:42:22+00:00

Currently, qemu-ga may die/get killed/go away for whatever reason after guest-fsfreeze-freeze has been issued, and before guest-fsfreeze-thaw has been issued. This means the only way to unfreeze the guest is via VNC/network/console access, but obtaining that access after-the-fact can often be very difficult when filesystems are frozen. Logins will almost always hang, for instance. In many cases the only recourse would be to reboot the guest without any quiescing of volatile state, which makes this a corner-case worth giving some attention to. A likely failsafe for this situation would be to use a watchdog to restart qemu-ga if it goes away. There are some precautions qemu-ga needs to take in order to avoid immediately hanging itself on I/O, however, namely, we must disable logging and defer to processing/creation of user-specific logfiles, along with creation of the pid file if we're running as a daemon. We also need to disable non-fsfreeze-safe commands, as we normally would when processing the guest-fsfreeze-freeze command. To track when we need to do this in a way that persists between multiple invocations of qemu-ga, we create a file on the guest filesystem before issuing the fsfreeze, and delete it when doing the thaw. On qemu-ga startup, we check for the existance of this file to determine the need to take the above precautions. We're forced to do it this way since a more traditional approach such as reading/writing state to a dedicated state file will cause access/modification time updates, respectively, both of which will hang if the file resides on a frozen filesystem. Both can occur even if relatime is enabled. Checking for file existence will not update the access time, however, so it's a safe way to check for fsfreeze state. An actual watchdog-based restart of qemu-ga can itself cause an access time update that would thus hang the invocation of qemu-ga, but the logic to workaround that can be handled via the watchdog, so we don't address that here (for relatime we'd periodically touch the qemu-ga binary if the file $qga_statedir/qga.state.isfrozen is not present, this avoids qemu-ga updates or the 1 day relatime threshold causing an access-time update if we try to respawn qemu-ga shortly after it goes away) Signed-off-by: Michael Roth