target-ppc: Move ppc tlb_fill implementation into mmu_helper.c
[qemu.git] / qga / qapi-schema.json
blobdac4e6f95fd2d35a99949d0dae056f831e8dc85f
1 # *-*- Mode: Python -*-*
3 ##
5 # Echo back a unique integer value, and prepend to response a
6 # leading sentinel byte (0xFF) the client can check scan for.
8 # This is used by clients talking to the guest agent over the
9 # wire to ensure the stream is in sync and doesn't contain stale
10 # data from previous client. It must be issued upon initial
11 # connection, and after any client-side timeouts (including
12 # timeouts on receiving a response to this command).
14 # After issuing this request, all guest agent responses should be
15 # ignored until the response containing the unique integer value
16 # the client passed in is returned. Receival of the 0xFF sentinel
17 # byte must be handled as an indication that the client's
18 # lexer/tokenizer/parser state should be flushed/reset in
19 # preparation for reliably receiving the subsequent response. As
20 # an optimization, clients may opt to ignore all data until a
21 # sentinel value is receiving to avoid unnecessary processing of
22 # stale data.
24 # Similarly, clients should also precede this *request*
25 # with a 0xFF byte to make sure the guest agent flushes any
26 # partially read JSON data from a previous client connection.
28 # @id: randomly generated 64-bit integer
30 # Returns: The unique integer id passed in by the client
32 # Since: 1.1
33 # ##
34 { 'command': 'guest-sync-delimited',
35   'data':    { 'id': 'int' },
36   'returns': 'int' }
39 # @guest-sync:
41 # Echo back a unique integer value
43 # This is used by clients talking to the guest agent over the
44 # wire to ensure the stream is in sync and doesn't contain stale
45 # data from previous client. All guest agent responses should be
46 # ignored until the provided unique integer value is returned,
47 # and it is up to the client to handle stale whole or
48 # partially-delivered JSON text in such a way that this response
49 # can be obtained.
51 # In cases where a partial stale response was previously
52 # received by the client, this cannot always be done reliably.
53 # One particular scenario being if qemu-ga responses are fed
54 # character-by-character into a JSON parser. In these situations,
55 # using guest-sync-delimited may be optimal.
57 # For clients that fetch responses line by line and convert them
58 # to JSON objects, guest-sync should be sufficient, but note that
59 # in cases where the channel is dirty some attempts at parsing the
60 # response may result in a parser error.
62 # Such clients should also precede this command
63 # with a 0xFF byte to make sure the guest agent flushes any
64 # partially read JSON data from a previous session.
66 # @id: randomly generated 64-bit integer
68 # Returns: The unique integer id passed in by the client
70 # Since: 0.15.0
72 { 'command': 'guest-sync',
73   'data':    { 'id': 'int' },
74   'returns': 'int' }
77 # @guest-ping:
79 # Ping the guest agent, a non-error return implies success
81 # Since: 0.15.0
83 { 'command': 'guest-ping' }
86 # @guest-get-time:
88 # Get the information about guest time relative to the Epoch
89 # of 1970-01-01 in UTC.
91 # Returns: Time in nanoseconds.
93 # Since 1.5
95 { 'command': 'guest-get-time',
96   'returns': 'int' }
99 # @guest-set-time:
101 # Set guest time.
103 # When a guest is paused or migrated to a file then loaded
104 # from that file, the guest OS has no idea that there
105 # was a big gap in the time. Depending on how long the
106 # gap was, NTP might not be able to resynchronize the
107 # guest.
109 # This command tries to set guest time to the given value,
110 # then sets the Hardware Clock to the current System Time.
111 # This will make it easier for a guest to resynchronize
112 # without waiting for NTP.
114 # @time: time of nanoseconds, relative to the Epoch of
115 #        1970-01-01 in UTC.
117 # Returns: Nothing on success.
119 # Since: 1.5
121 { 'command': 'guest-set-time',
122   'data': { 'time': 'int' } }
125 # @GuestAgentCommandInfo:
127 # Information about guest agent commands.
129 # @name: name of the command
131 # @enabled: whether command is currently enabled by guest admin
133 # Since 1.1.0
135 { 'type': 'GuestAgentCommandInfo',
136   'data': { 'name': 'str', 'enabled': 'bool' } }
139 # @GuestAgentInfo
141 # Information about guest agent.
143 # @version: guest agent version
145 # @supported_commands: Information about guest agent commands
147 # Since 0.15.0
149 { 'type': 'GuestAgentInfo',
150   'data': { 'version': 'str',
151             'supported_commands': ['GuestAgentCommandInfo'] } }
153 # @guest-info:
155 # Get some information about the guest agent.
157 # Returns: @GuestAgentInfo
159 # Since: 0.15.0
161 { 'command': 'guest-info',
162   'returns': 'GuestAgentInfo' }
165 # @guest-shutdown:
167 # Initiate guest-activated shutdown. Note: this is an asynchronous
168 # shutdown request, with no guarantee of successful shutdown.
170 # @mode: #optional "halt", "powerdown" (default), or "reboot"
172 # This command does NOT return a response on success. Success condition
173 # is indicated by the VM exiting with a zero exit status or, when
174 # running with --no-shutdown, by issuing the query-status QMP command
175 # to confirm the VM status is "shutdown".
177 # Since: 0.15.0
179 { 'command': 'guest-shutdown', 'data': { '*mode': 'str' },
180   'success-response': 'no' }
183 # @guest-file-open:
185 # Open a file in the guest and retrieve a file handle for it
187 # @filepath: Full path to the file in the guest to open.
189 # @mode: #optional open mode, as per fopen(), "r" is the default.
191 # Returns: Guest file handle on success.
193 # Since: 0.15.0
195 { 'command': 'guest-file-open',
196   'data':    { 'path': 'str', '*mode': 'str' },
197   'returns': 'int' }
200 # @guest-file-close:
202 # Close an open file in the guest
204 # @handle: filehandle returned by guest-file-open
206 # Returns: Nothing on success.
208 # Since: 0.15.0
210 { 'command': 'guest-file-close',
211   'data': { 'handle': 'int' } }
214 # @GuestFileRead
216 # Result of guest agent file-read operation
218 # @count: number of bytes read (note: count is *before*
219 #         base64-encoding is applied)
221 # @buf-b64: base64-encoded bytes read
223 # @eof: whether EOF was encountered during read operation.
225 # Since: 0.15.0
227 { 'type': 'GuestFileRead',
228   'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
231 # @guest-file-read:
233 # Read from an open file in the guest. Data will be base64-encoded
235 # @handle: filehandle returned by guest-file-open
237 # @count: #optional maximum number of bytes to read (default is 4KB)
239 # Returns: @GuestFileRead on success.
241 # Since: 0.15.0
243 { 'command': 'guest-file-read',
244   'data':    { 'handle': 'int', '*count': 'int' },
245   'returns': 'GuestFileRead' }
248 # @GuestFileWrite
250 # Result of guest agent file-write operation
252 # @count: number of bytes written (note: count is actual bytes
253 #         written, after base64-decoding of provided buffer)
255 # @eof: whether EOF was encountered during write operation.
257 # Since: 0.15.0
259 { 'type': 'GuestFileWrite',
260   'data': { 'count': 'int', 'eof': 'bool' } }
263 # @guest-file-write:
265 # Write to an open file in the guest.
267 # @handle: filehandle returned by guest-file-open
269 # @buf-b64: base64-encoded string representing data to be written
271 # @count: #optional bytes to write (actual bytes, after base64-decode),
272 #         default is all content in buf-b64 buffer after base64 decoding
274 # Returns: @GuestFileWrite on success.
276 # Since: 0.15.0
278 { 'command': 'guest-file-write',
279   'data':    { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' },
280   'returns': 'GuestFileWrite' }
284 # @GuestFileSeek
286 # Result of guest agent file-seek operation
288 # @position: current file position
290 # @eof: whether EOF was encountered during file seek
292 # Since: 0.15.0
294 { 'type': 'GuestFileSeek',
295   'data': { 'position': 'int', 'eof': 'bool' } }
298 # @guest-file-seek:
300 # Seek to a position in the file, as with fseek(), and return the
301 # current file position afterward. Also encapsulates ftell()'s
302 # functionality, just Set offset=0, whence=SEEK_CUR.
304 # @handle: filehandle returned by guest-file-open
306 # @offset: bytes to skip over in the file stream
308 # @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek()
310 # Returns: @GuestFileSeek on success.
312 # Since: 0.15.0
314 { 'command': 'guest-file-seek',
315   'data':    { 'handle': 'int', 'offset': 'int', 'whence': 'int' },
316   'returns': 'GuestFileSeek' }
319 # @guest-file-flush:
321 # Write file changes bufferred in userspace to disk/kernel buffers
323 # @handle: filehandle returned by guest-file-open
325 # Returns: Nothing on success.
327 # Since: 0.15.0
329 { 'command': 'guest-file-flush',
330   'data': { 'handle': 'int' } }
333 # @GuestFsFreezeStatus
335 # An enumeration of filesystem freeze states
337 # @thawed: filesystems thawed/unfrozen
339 # @frozen: all non-network guest filesystems frozen
341 # Since: 0.15.0
343 { 'enum': 'GuestFsfreezeStatus',
344   'data': [ 'thawed', 'frozen' ] }
347 # @guest-fsfreeze-status:
349 # Get guest fsfreeze state. error state indicates
351 # Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined below)
353 # Note: This may fail to properly report the current state as a result of
354 # some other guest processes having issued an fs freeze/thaw.
356 # Since: 0.15.0
358 { 'command': 'guest-fsfreeze-status',
359   'returns': 'GuestFsfreezeStatus' }
362 # @guest-fsfreeze-freeze:
364 # Sync and freeze all freezable, local guest filesystems
366 # Returns: Number of file systems currently frozen. On error, all filesystems
367 # will be thawed.
369 # Since: 0.15.0
371 { 'command': 'guest-fsfreeze-freeze',
372   'returns': 'int' }
375 # @guest-fsfreeze-thaw:
377 # Unfreeze all frozen guest filesystems
379 # Returns: Number of file systems thawed by this call
381 # Note: if return value does not match the previous call to
382 #       guest-fsfreeze-freeze, this likely means some freezable
383 #       filesystems were unfrozen before this call, and that the
384 #       filesystem state may have changed before issuing this
385 #       command.
387 # Since: 0.15.0
389 { 'command': 'guest-fsfreeze-thaw',
390   'returns': 'int' }
393 # @guest-fstrim:
395 # Discard (or "trim") blocks which are not in use by the filesystem.
397 # @minimum:
398 #       Minimum contiguous free range to discard, in bytes. Free ranges
399 #       smaller than this may be ignored (this is a hint and the guest
400 #       may not respect it).  By increasing this value, the fstrim
401 #       operation will complete more quickly for filesystems with badly
402 #       fragmented free space, although not all blocks will be discarded.
403 #       The default value is zero, meaning "discard every free block".
405 # Returns: Nothing.
407 # Since: 1.2
409 { 'command': 'guest-fstrim',
410   'data': { '*minimum': 'int' } }
413 # @guest-suspend-disk
415 # Suspend guest to disk.
417 # This command tries to execute the scripts provided by the pm-utils package.
418 # If it's not available, the suspend operation will be performed by manually
419 # writing to a sysfs file.
421 # For the best results it's strongly recommended to have the pm-utils
422 # package installed in the guest.
424 # This command does NOT return a response on success. There is a high chance
425 # the command succeeded if the VM exits with a zero exit status or, when
426 # running with --no-shutdown, by issuing the query-status QMP command to
427 # to confirm the VM status is "shutdown". However, the VM could also exit
428 # (or set its status to "shutdown") due to other reasons.
430 # The following errors may be returned:
431 #          If suspend to disk is not supported, Unsupported
433 # Notes: It's strongly recommended to issue the guest-sync command before
434 #        sending commands when the guest resumes
436 # Since: 1.1
438 { 'command': 'guest-suspend-disk', 'success-response': 'no' }
441 # @guest-suspend-ram
443 # Suspend guest to ram.
445 # This command tries to execute the scripts provided by the pm-utils package.
446 # If it's not available, the suspend operation will be performed by manually
447 # writing to a sysfs file.
449 # For the best results it's strongly recommended to have the pm-utils
450 # package installed in the guest.
452 # IMPORTANT: guest-suspend-ram requires QEMU to support the 'system_wakeup'
453 # command.  Thus, it's *required* to query QEMU for the presence of the
454 # 'system_wakeup' command before issuing guest-suspend-ram.
456 # This command does NOT return a response on success. There are two options
457 # to check for success:
458 #   1. Wait for the SUSPEND QMP event from QEMU
459 #   2. Issue the query-status QMP command to confirm the VM status is
460 #      "suspended"
462 # The following errors may be returned:
463 #          If suspend to ram is not supported, Unsupported
465 # Notes: It's strongly recommended to issue the guest-sync command before
466 #        sending commands when the guest resumes
468 # Since: 1.1
470 { 'command': 'guest-suspend-ram', 'success-response': 'no' }
473 # @guest-suspend-hybrid
475 # Save guest state to disk and suspend to ram.
477 # This command requires the pm-utils package to be installed in the guest.
479 # IMPORTANT: guest-suspend-hybrid requires QEMU to support the 'system_wakeup'
480 # command.  Thus, it's *required* to query QEMU for the presence of the
481 # 'system_wakeup' command before issuing guest-suspend-hybrid.
483 # This command does NOT return a response on success. There are two options
484 # to check for success:
485 #   1. Wait for the SUSPEND QMP event from QEMU
486 #   2. Issue the query-status QMP command to confirm the VM status is
487 #      "suspended"
489 # The following errors may be returned:
490 #          If hybrid suspend is not supported, Unsupported
492 # Notes: It's strongly recommended to issue the guest-sync command before
493 #        sending commands when the guest resumes
495 # Since: 1.1
497 { 'command': 'guest-suspend-hybrid', 'success-response': 'no' }
500 # @GuestIpAddressType:
502 # An enumeration of supported IP address types
504 # @ipv4: IP version 4
506 # @ipv6: IP version 6
508 # Since: 1.1
510 { 'enum': 'GuestIpAddressType',
511   'data': [ 'ipv4', 'ipv6' ] }
514 # @GuestIpAddress:
516 # @ip-address: IP address
518 # @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6)
520 # @prefix: Network prefix length of @ip-address
522 # Since: 1.1
524 { 'type': 'GuestIpAddress',
525   'data': {'ip-address': 'str',
526            'ip-address-type': 'GuestIpAddressType',
527            'prefix': 'int'} }
530 # @GuestNetworkInterface:
532 # @name: The name of interface for which info are being delivered
534 # @hardware-address: Hardware address of @name
536 # @ip-addresses: List of addresses assigned to @name
538 # Since: 1.1
540 { 'type': 'GuestNetworkInterface',
541   'data': {'name': 'str',
542            '*hardware-address': 'str',
543            '*ip-addresses': ['GuestIpAddress'] } }
546 # @guest-network-get-interfaces:
548 # Get list of guest IP addresses, MAC addresses
549 # and netmasks.
551 # Returns: List of GuestNetworkInfo on success.
553 # Since: 1.1
555 { 'command': 'guest-network-get-interfaces',
556   'returns': ['GuestNetworkInterface'] }
559 # @GuestLogicalProcessor:
561 # @logical-id: Arbitrary guest-specific unique identifier of the VCPU.
563 # @online: Whether the VCPU is enabled.
565 # @can-offline: Whether offlining the VCPU is possible. This member is always
566 #               filled in by the guest agent when the structure is returned,
567 #               and always ignored on input (hence it can be omitted then).
569 # Since: 1.5
571 { 'type': 'GuestLogicalProcessor',
572   'data': {'logical-id': 'int',
573            'online': 'bool',
574            '*can-offline': 'bool'} }
577 # @guest-get-vcpus:
579 # Retrieve the list of the guest's logical processors.
581 # This is a read-only operation.
583 # Returns: The list of all VCPUs the guest knows about. Each VCPU is put on the
584 # list exactly once, but their order is unspecified.
586 # Since: 1.5
588 { 'command': 'guest-get-vcpus',
589   'returns': ['GuestLogicalProcessor'] }
592 # @guest-set-vcpus:
594 # Attempt to reconfigure (currently: enable/disable) logical processors inside
595 # the guest.
597 # The input list is processed node by node in order. In each node @logical-id
598 # is used to look up the guest VCPU, for which @online specifies the requested
599 # state. The set of distinct @logical-id's is only required to be a subset of
600 # the guest-supported identifiers. There's no restriction on list length or on
601 # repeating the same @logical-id (with possibly different @online field).
602 # Preferably the input list should describe a modified subset of
603 # @guest-get-vcpus' return value.
605 # Returns: The length of the initial sublist that has been successfully
606 #          processed. The guest agent maximizes this value. Possible cases:
608 #          0:                if the @vcpus list was empty on input. Guest state
609 #                            has not been changed. Otherwise,
611 #          Error:            processing the first node of @vcpus failed for the
612 #                            reason returned. Guest state has not been changed.
613 #                            Otherwise,
615 #          < length(@vcpus): more than zero initial nodes have been processed,
616 #                            but not the entire @vcpus list. Guest state has
617 #                            changed accordingly. To retrieve the error
618 #                            (assuming it persists), repeat the call with the
619 #                            successfully processed initial sublist removed.
620 #                            Otherwise,
622 #          length(@vcpus):   call successful.
624 # Since: 1.5
626 { 'command': 'guest-set-vcpus',
627   'data':    {'vcpus': ['GuestLogicalProcessor'] },
628   'returns': 'int' }