xref: /openbmc/qemu/qga/qapi-schema.json (revision 6775e2c4)
1# *-*- Mode: Python -*-*
2
3##
4#
5# General note concerning the use of guest agent interfaces:
6#
7# "unsupported" is a higher-level error than the errors that individual
8# commands might document. The caller should always be prepared to receive
9# QERR_UNSUPPORTED, even if the given command doesn't specify it, or doesn't
10# document any failure mode at all.
11#
12##
13
14##
15#
16# Echo back a unique integer value, and prepend to response a
17# leading sentinel byte (0xFF) the client can check scan for.
18#
19# This is used by clients talking to the guest agent over the
20# wire to ensure the stream is in sync and doesn't contain stale
21# data from previous client. It must be issued upon initial
22# connection, and after any client-side timeouts (including
23# timeouts on receiving a response to this command).
24#
25# After issuing this request, all guest agent responses should be
26# ignored until the response containing the unique integer value
27# the client passed in is returned. Receival of the 0xFF sentinel
28# byte must be handled as an indication that the client's
29# lexer/tokenizer/parser state should be flushed/reset in
30# preparation for reliably receiving the subsequent response. As
31# an optimization, clients may opt to ignore all data until a
32# sentinel value is receiving to avoid unnecessary processing of
33# stale data.
34#
35# Similarly, clients should also precede this *request*
36# with a 0xFF byte to make sure the guest agent flushes any
37# partially read JSON data from a previous client connection.
38#
39# @id: randomly generated 64-bit integer
40#
41# Returns: The unique integer id passed in by the client
42#
43# Since: 1.1
44# ##
45{ 'command': 'guest-sync-delimited',
46  'data':    { 'id': 'int' },
47  'returns': 'int' }
48
49##
50# @guest-sync:
51#
52# Echo back a unique integer value
53#
54# This is used by clients talking to the guest agent over the
55# wire to ensure the stream is in sync and doesn't contain stale
56# data from previous client. All guest agent responses should be
57# ignored until the provided unique integer value is returned,
58# and it is up to the client to handle stale whole or
59# partially-delivered JSON text in such a way that this response
60# can be obtained.
61#
62# In cases where a partial stale response was previously
63# received by the client, this cannot always be done reliably.
64# One particular scenario being if qemu-ga responses are fed
65# character-by-character into a JSON parser. In these situations,
66# using guest-sync-delimited may be optimal.
67#
68# For clients that fetch responses line by line and convert them
69# to JSON objects, guest-sync should be sufficient, but note that
70# in cases where the channel is dirty some attempts at parsing the
71# response may result in a parser error.
72#
73# Such clients should also precede this command
74# with a 0xFF byte to make sure the guest agent flushes any
75# partially read JSON data from a previous session.
76#
77# @id: randomly generated 64-bit integer
78#
79# Returns: The unique integer id passed in by the client
80#
81# Since: 0.15.0
82##
83{ 'command': 'guest-sync',
84  'data':    { 'id': 'int' },
85  'returns': 'int' }
86
87##
88# @guest-ping:
89#
90# Ping the guest agent, a non-error return implies success
91#
92# Since: 0.15.0
93##
94{ 'command': 'guest-ping' }
95
96##
97# @guest-get-time:
98#
99# Get the information about guest's System Time relative to
100# the Epoch of 1970-01-01 in UTC.
101#
102# Returns: Time in nanoseconds.
103#
104# Since 1.5
105##
106{ 'command': 'guest-get-time',
107  'returns': 'int' }
108
109##
110# @guest-set-time:
111#
112# Set guest time.
113#
114# When a guest is paused or migrated to a file then loaded
115# from that file, the guest OS has no idea that there
116# was a big gap in the time. Depending on how long the
117# gap was, NTP might not be able to resynchronize the
118# guest.
119#
120# This command tries to set guest's System Time to the
121# given value, then sets the Hardware Clock (RTC) to the
122# current System Time. This will make it easier for a guest
123# to resynchronize without waiting for NTP. If no @time is
124# specified, then the time to set is read from RTC. However,
125# this may not be supported on all platforms (i.e. Windows).
126# If that's the case users are advised to always pass a
127# value.
128#
129# @time: #optional time of nanoseconds, relative to the Epoch
130#        of 1970-01-01 in UTC.
131#
132# Returns: Nothing on success.
133#
134# Since: 1.5
135##
136{ 'command': 'guest-set-time',
137  'data': { '*time': 'int' } }
138
139##
140# @GuestAgentCommandInfo:
141#
142# Information about guest agent commands.
143#
144# @name: name of the command
145#
146# @enabled: whether command is currently enabled by guest admin
147#
148# @success-response: whether command returns a response on success
149#                    (since 1.7)
150#
151# Since 1.1.0
152##
153{ 'struct': 'GuestAgentCommandInfo',
154  'data': { 'name': 'str', 'enabled': 'bool', 'success-response': 'bool' } }
155
156##
157# @GuestAgentInfo
158#
159# Information about guest agent.
160#
161# @version: guest agent version
162#
163# @supported_commands: Information about guest agent commands
164#
165# Since 0.15.0
166##
167{ 'struct': 'GuestAgentInfo',
168  'data': { 'version': 'str',
169            'supported_commands': ['GuestAgentCommandInfo'] } }
170##
171# @guest-info:
172#
173# Get some information about the guest agent.
174#
175# Returns: @GuestAgentInfo
176#
177# Since: 0.15.0
178##
179{ 'command': 'guest-info',
180  'returns': 'GuestAgentInfo' }
181
182##
183# @guest-shutdown:
184#
185# Initiate guest-activated shutdown. Note: this is an asynchronous
186# shutdown request, with no guarantee of successful shutdown.
187#
188# @mode: #optional "halt", "powerdown" (default), or "reboot"
189#
190# This command does NOT return a response on success. Success condition
191# is indicated by the VM exiting with a zero exit status or, when
192# running with --no-shutdown, by issuing the query-status QMP command
193# to confirm the VM status is "shutdown".
194#
195# Since: 0.15.0
196##
197{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' },
198  'success-response': false }
199
200##
201# @guest-file-open:
202#
203# Open a file in the guest and retrieve a file handle for it
204#
205# @filepath: Full path to the file in the guest to open.
206#
207# @mode: #optional open mode, as per fopen(), "r" is the default.
208#
209# Returns: Guest file handle on success.
210#
211# Since: 0.15.0
212##
213{ 'command': 'guest-file-open',
214  'data':    { 'path': 'str', '*mode': 'str' },
215  'returns': 'int' }
216
217##
218# @guest-file-close:
219#
220# Close an open file in the guest
221#
222# @handle: filehandle returned by guest-file-open
223#
224# Returns: Nothing on success.
225#
226# Since: 0.15.0
227##
228{ 'command': 'guest-file-close',
229  'data': { 'handle': 'int' } }
230
231##
232# @GuestFileRead
233#
234# Result of guest agent file-read operation
235#
236# @count: number of bytes read (note: count is *before*
237#         base64-encoding is applied)
238#
239# @buf-b64: base64-encoded bytes read
240#
241# @eof: whether EOF was encountered during read operation.
242#
243# Since: 0.15.0
244##
245{ 'struct': 'GuestFileRead',
246  'data': { 'count': 'int', 'buf-b64': 'str', 'eof': 'bool' } }
247
248##
249# @guest-file-read:
250#
251# Read from an open file in the guest. Data will be base64-encoded
252#
253# @handle: filehandle returned by guest-file-open
254#
255# @count: #optional maximum number of bytes to read (default is 4KB)
256#
257# Returns: @GuestFileRead on success.
258#
259# Since: 0.15.0
260##
261{ 'command': 'guest-file-read',
262  'data':    { 'handle': 'int', '*count': 'int' },
263  'returns': 'GuestFileRead' }
264
265##
266# @GuestFileWrite
267#
268# Result of guest agent file-write operation
269#
270# @count: number of bytes written (note: count is actual bytes
271#         written, after base64-decoding of provided buffer)
272#
273# @eof: whether EOF was encountered during write operation.
274#
275# Since: 0.15.0
276##
277{ 'struct': 'GuestFileWrite',
278  'data': { 'count': 'int', 'eof': 'bool' } }
279
280##
281# @guest-file-write:
282#
283# Write to an open file in the guest.
284#
285# @handle: filehandle returned by guest-file-open
286#
287# @buf-b64: base64-encoded string representing data to be written
288#
289# @count: #optional bytes to write (actual bytes, after base64-decode),
290#         default is all content in buf-b64 buffer after base64 decoding
291#
292# Returns: @GuestFileWrite on success.
293#
294# Since: 0.15.0
295##
296{ 'command': 'guest-file-write',
297  'data':    { 'handle': 'int', 'buf-b64': 'str', '*count': 'int' },
298  'returns': 'GuestFileWrite' }
299
300
301##
302# @GuestFileSeek
303#
304# Result of guest agent file-seek operation
305#
306# @position: current file position
307#
308# @eof: whether EOF was encountered during file seek
309#
310# Since: 0.15.0
311##
312{ 'struct': 'GuestFileSeek',
313  'data': { 'position': 'int', 'eof': 'bool' } }
314
315##
316# @guest-file-seek:
317#
318# Seek to a position in the file, as with fseek(), and return the
319# current file position afterward. Also encapsulates ftell()'s
320# functionality, just Set offset=0, whence=SEEK_CUR.
321#
322# @handle: filehandle returned by guest-file-open
323#
324# @offset: bytes to skip over in the file stream
325#
326# @whence: SEEK_SET, SEEK_CUR, or SEEK_END, as with fseek()
327#
328# Returns: @GuestFileSeek on success.
329#
330# Since: 0.15.0
331##
332{ 'command': 'guest-file-seek',
333  'data':    { 'handle': 'int', 'offset': 'int', 'whence': 'int' },
334  'returns': 'GuestFileSeek' }
335
336##
337# @guest-file-flush:
338#
339# Write file changes bufferred in userspace to disk/kernel buffers
340#
341# @handle: filehandle returned by guest-file-open
342#
343# Returns: Nothing on success.
344#
345# Since: 0.15.0
346##
347{ 'command': 'guest-file-flush',
348  'data': { 'handle': 'int' } }
349
350##
351# @GuestFsFreezeStatus
352#
353# An enumeration of filesystem freeze states
354#
355# @thawed: filesystems thawed/unfrozen
356#
357# @frozen: all non-network guest filesystems frozen
358#
359# Since: 0.15.0
360##
361{ 'enum': 'GuestFsfreezeStatus',
362  'data': [ 'thawed', 'frozen' ] }
363
364##
365# @guest-fsfreeze-status:
366#
367# Get guest fsfreeze state. error state indicates
368#
369# Returns: GuestFsfreezeStatus ("thawed", "frozen", etc., as defined below)
370#
371# Note: This may fail to properly report the current state as a result of
372# some other guest processes having issued an fs freeze/thaw.
373#
374# Since: 0.15.0
375##
376{ 'command': 'guest-fsfreeze-status',
377  'returns': 'GuestFsfreezeStatus' }
378
379##
380# @guest-fsfreeze-freeze:
381#
382# Sync and freeze all freezable, local guest filesystems
383#
384# Returns: Number of file systems currently frozen. On error, all filesystems
385# will be thawed.
386#
387# Since: 0.15.0
388##
389{ 'command': 'guest-fsfreeze-freeze',
390  'returns': 'int' }
391
392##
393# @guest-fsfreeze-freeze-list:
394#
395# Sync and freeze specified guest filesystems
396#
397# @mountpoints: #optional an array of mountpoints of filesystems to be frozen.
398#               If omitted, every mounted filesystem is frozen.
399#
400# Returns: Number of file systems currently frozen. On error, all filesystems
401# will be thawed.
402#
403# Since: 2.2
404##
405{ 'command': 'guest-fsfreeze-freeze-list',
406  'data':    { '*mountpoints': ['str'] },
407  'returns': 'int' }
408
409##
410# @guest-fsfreeze-thaw:
411#
412# Unfreeze all frozen guest filesystems
413#
414# Returns: Number of file systems thawed by this call
415#
416# Note: if return value does not match the previous call to
417#       guest-fsfreeze-freeze, this likely means some freezable
418#       filesystems were unfrozen before this call, and that the
419#       filesystem state may have changed before issuing this
420#       command.
421#
422# Since: 0.15.0
423##
424{ 'command': 'guest-fsfreeze-thaw',
425  'returns': 'int' }
426
427##
428# @GuestFilesystemTrimResult
429#
430# @path: path that was trimmed
431# @error: an error message when trim failed
432# @trimmed: bytes trimmed for this path
433# @minimum: reported effective minimum for this path
434#
435# Since: 2.4
436##
437{ 'struct': 'GuestFilesystemTrimResult',
438  'data': {'path': 'str',
439           '*trimmed': 'int', '*minimum': 'int', '*error': 'str'} }
440
441##
442# @GuestFilesystemTrimResponse
443#
444# @paths: list of @GuestFilesystemTrimResult per path that was trimmed
445#
446# Since: 2.4
447##
448{ 'struct': 'GuestFilesystemTrimResponse',
449  'data': {'paths': ['GuestFilesystemTrimResult']} }
450
451##
452# @guest-fstrim:
453#
454# Discard (or "trim") blocks which are not in use by the filesystem.
455#
456# @minimum:
457#       Minimum contiguous free range to discard, in bytes. Free ranges
458#       smaller than this may be ignored (this is a hint and the guest
459#       may not respect it).  By increasing this value, the fstrim
460#       operation will complete more quickly for filesystems with badly
461#       fragmented free space, although not all blocks will be discarded.
462#       The default value is zero, meaning "discard every free block".
463#
464# Returns: A @GuestFilesystemTrimResponse which contains the
465#          status of all trimmed paths. (since 2.4)
466#
467# Since: 1.2
468##
469{ 'command': 'guest-fstrim',
470  'data': { '*minimum': 'int' },
471  'returns': 'GuestFilesystemTrimResponse' }
472
473##
474# @guest-suspend-disk
475#
476# Suspend guest to disk.
477#
478# This command tries to execute the scripts provided by the pm-utils package.
479# If it's not available, the suspend operation will be performed by manually
480# writing to a sysfs file.
481#
482# For the best results it's strongly recommended to have the pm-utils
483# package installed in the guest.
484#
485# This command does NOT return a response on success. There is a high chance
486# the command succeeded if the VM exits with a zero exit status or, when
487# running with --no-shutdown, by issuing the query-status QMP command to
488# to confirm the VM status is "shutdown". However, the VM could also exit
489# (or set its status to "shutdown") due to other reasons.
490#
491# The following errors may be returned:
492#          If suspend to disk is not supported, Unsupported
493#
494# Notes: It's strongly recommended to issue the guest-sync command before
495#        sending commands when the guest resumes
496#
497# Since: 1.1
498##
499{ 'command': 'guest-suspend-disk', 'success-response': false }
500
501##
502# @guest-suspend-ram
503#
504# Suspend guest to ram.
505#
506# This command tries to execute the scripts provided by the pm-utils package.
507# If it's not available, the suspend operation will be performed by manually
508# writing to a sysfs file.
509#
510# For the best results it's strongly recommended to have the pm-utils
511# package installed in the guest.
512#
513# IMPORTANT: guest-suspend-ram requires QEMU to support the 'system_wakeup'
514# command.  Thus, it's *required* to query QEMU for the presence of the
515# 'system_wakeup' command before issuing guest-suspend-ram.
516#
517# This command does NOT return a response on success. There are two options
518# to check for success:
519#   1. Wait for the SUSPEND QMP event from QEMU
520#   2. Issue the query-status QMP command to confirm the VM status is
521#      "suspended"
522#
523# The following errors may be returned:
524#          If suspend to ram is not supported, Unsupported
525#
526# Notes: It's strongly recommended to issue the guest-sync command before
527#        sending commands when the guest resumes
528#
529# Since: 1.1
530##
531{ 'command': 'guest-suspend-ram', 'success-response': false }
532
533##
534# @guest-suspend-hybrid
535#
536# Save guest state to disk and suspend to ram.
537#
538# This command requires the pm-utils package to be installed in the guest.
539#
540# IMPORTANT: guest-suspend-hybrid requires QEMU to support the 'system_wakeup'
541# command.  Thus, it's *required* to query QEMU for the presence of the
542# 'system_wakeup' command before issuing guest-suspend-hybrid.
543#
544# This command does NOT return a response on success. There are two options
545# to check for success:
546#   1. Wait for the SUSPEND QMP event from QEMU
547#   2. Issue the query-status QMP command to confirm the VM status is
548#      "suspended"
549#
550# The following errors may be returned:
551#          If hybrid suspend is not supported, Unsupported
552#
553# Notes: It's strongly recommended to issue the guest-sync command before
554#        sending commands when the guest resumes
555#
556# Since: 1.1
557##
558{ 'command': 'guest-suspend-hybrid', 'success-response': false }
559
560##
561# @GuestIpAddressType:
562#
563# An enumeration of supported IP address types
564#
565# @ipv4: IP version 4
566#
567# @ipv6: IP version 6
568#
569# Since: 1.1
570##
571{ 'enum': 'GuestIpAddressType',
572  'data': [ 'ipv4', 'ipv6' ] }
573
574##
575# @GuestIpAddress:
576#
577# @ip-address: IP address
578#
579# @ip-address-type: Type of @ip-address (e.g. ipv4, ipv6)
580#
581# @prefix: Network prefix length of @ip-address
582#
583# Since: 1.1
584##
585{ 'struct': 'GuestIpAddress',
586  'data': {'ip-address': 'str',
587           'ip-address-type': 'GuestIpAddressType',
588           'prefix': 'int'} }
589
590##
591# @GuestNetworkInterface:
592#
593# @name: The name of interface for which info are being delivered
594#
595# @hardware-address: Hardware address of @name
596#
597# @ip-addresses: List of addresses assigned to @name
598#
599# Since: 1.1
600##
601{ 'struct': 'GuestNetworkInterface',
602  'data': {'name': 'str',
603           '*hardware-address': 'str',
604           '*ip-addresses': ['GuestIpAddress'] } }
605
606##
607# @guest-network-get-interfaces:
608#
609# Get list of guest IP addresses, MAC addresses
610# and netmasks.
611#
612# Returns: List of GuestNetworkInfo on success.
613#
614# Since: 1.1
615##
616{ 'command': 'guest-network-get-interfaces',
617  'returns': ['GuestNetworkInterface'] }
618
619##
620# @GuestLogicalProcessor:
621#
622# @logical-id: Arbitrary guest-specific unique identifier of the VCPU.
623#
624# @online: Whether the VCPU is enabled.
625#
626# @can-offline: #optional Whether offlining the VCPU is possible. This member
627#               is always filled in by the guest agent when the structure is
628#               returned, and always ignored on input (hence it can be omitted
629#               then).
630#
631# Since: 1.5
632##
633{ 'struct': 'GuestLogicalProcessor',
634  'data': {'logical-id': 'int',
635           'online': 'bool',
636           '*can-offline': 'bool'} }
637
638##
639# @guest-get-vcpus:
640#
641# Retrieve the list of the guest's logical processors.
642#
643# This is a read-only operation.
644#
645# Returns: The list of all VCPUs the guest knows about. Each VCPU is put on the
646# list exactly once, but their order is unspecified.
647#
648# Since: 1.5
649##
650{ 'command': 'guest-get-vcpus',
651  'returns': ['GuestLogicalProcessor'] }
652
653##
654# @guest-set-vcpus:
655#
656# Attempt to reconfigure (currently: enable/disable) logical processors inside
657# the guest.
658#
659# The input list is processed node by node in order. In each node @logical-id
660# is used to look up the guest VCPU, for which @online specifies the requested
661# state. The set of distinct @logical-id's is only required to be a subset of
662# the guest-supported identifiers. There's no restriction on list length or on
663# repeating the same @logical-id (with possibly different @online field).
664# Preferably the input list should describe a modified subset of
665# @guest-get-vcpus' return value.
666#
667# Returns: The length of the initial sublist that has been successfully
668#          processed. The guest agent maximizes this value. Possible cases:
669#
670#          0:                if the @vcpus list was empty on input. Guest state
671#                            has not been changed. Otherwise,
672#
673#          Error:            processing the first node of @vcpus failed for the
674#                            reason returned. Guest state has not been changed.
675#                            Otherwise,
676#
677#          < length(@vcpus): more than zero initial nodes have been processed,
678#                            but not the entire @vcpus list. Guest state has
679#                            changed accordingly. To retrieve the error
680#                            (assuming it persists), repeat the call with the
681#                            successfully processed initial sublist removed.
682#                            Otherwise,
683#
684#          length(@vcpus):   call successful.
685#
686# Since: 1.5
687##
688{ 'command': 'guest-set-vcpus',
689  'data':    {'vcpus': ['GuestLogicalProcessor'] },
690  'returns': 'int' }
691
692##
693# @GuestDiskBusType
694#
695# An enumeration of bus type of disks
696#
697# @ide: IDE disks
698# @fdc: floppy disks
699# @scsi: SCSI disks
700# @virtio: virtio disks
701# @xen: Xen disks
702# @usb: USB disks
703# @uml: UML disks
704# @sata: SATA disks
705# @sd: SD cards
706# @unknown: Unknown bus type
707# @ieee1394: Win IEEE 1394 bus type
708# @ssa: Win SSA bus type
709# @fibre: Win fiber channel bus type
710# @raid: Win RAID bus type
711# @iscsi: Win iScsi bus type
712# @sas: Win serial-attaches SCSI bus type
713# @mmc: Win multimedia card (MMC) bus type
714# @virtual: Win virtual bus type
715# @file-backed virtual: Win file-backed bus type
716#
717# Since: 2.2; 'Unknown' and all entries below since 2.4
718##
719{ 'enum': 'GuestDiskBusType',
720  'data': [ 'ide', 'fdc', 'scsi', 'virtio', 'xen', 'usb', 'uml', 'sata',
721            'sd', 'unknown', 'ieee1394', 'ssa', 'fibre', 'raid', 'iscsi',
722            'sas', 'mmc', 'virtual', 'file-backed-virtual' ] }
723
724
725##
726# @GuestPCIAddress:
727#
728# @domain: domain id
729# @bus: bus id
730# @slot: slot id
731# @function: function id
732#
733# Since: 2.2
734##
735{ 'struct': 'GuestPCIAddress',
736  'data': {'domain': 'int', 'bus': 'int',
737           'slot': 'int', 'function': 'int'} }
738
739##
740# @GuestDiskAddress:
741#
742# @pci-controller: controller's PCI address
743# @type: bus type
744# @bus: bus id
745# @target: target id
746# @unit: unit id
747#
748# Since: 2.2
749##
750{ 'struct': 'GuestDiskAddress',
751  'data': {'pci-controller': 'GuestPCIAddress',
752           'bus-type': 'GuestDiskBusType',
753           'bus': 'int', 'target': 'int', 'unit': 'int'} }
754
755##
756# @GuestFilesystemInfo
757#
758# @name: disk name
759# @mountpoint: mount point path
760# @type: file system type string
761# @disk: an array of disk hardware information that the volume lies on,
762#        which may be empty if the disk type is not supported
763#
764# Since: 2.2
765##
766{ 'struct': 'GuestFilesystemInfo',
767  'data': {'name': 'str', 'mountpoint': 'str', 'type': 'str',
768           'disk': ['GuestDiskAddress']} }
769
770##
771# @guest-get-fsinfo:
772#
773# Returns: The list of filesystems information mounted in the guest.
774#          The returned mountpoints may be specified to
775#          @guest-fsfreeze-freeze-list.
776#          Network filesystems (such as CIFS and NFS) are not listed.
777#
778# Since: 2.2
779##
780{ 'command': 'guest-get-fsinfo',
781  'returns': ['GuestFilesystemInfo'] }
782
783##
784# @guest-set-user-password
785#
786# @username: the user account whose password to change
787# @password: the new password entry string, base64 encoded
788# @crypted: true if password is already crypt()d, false if raw
789#
790# If the @crypted flag is true, it is the caller's responsibility
791# to ensure the correct crypt() encryption scheme is used. This
792# command does not attempt to interpret or report on the encryption
793# scheme. Refer to the documentation of the guest operating system
794# in question to determine what is supported.
795#
796# Note all guest operating systems will support use of the
797# @crypted flag, as they may require the clear-text password
798#
799# The @password parameter must always be base64 encoded before
800# transmission, even if already crypt()d, to ensure it is 8-bit
801# safe when passed as JSON.
802#
803# Returns: Nothing on success.
804#
805# Since 2.3
806##
807{ 'command': 'guest-set-user-password',
808  'data': { 'username': 'str', 'password': 'str', 'crypted': 'bool' } }
809
810# @GuestMemoryBlock:
811#
812# @phys-index: Arbitrary guest-specific unique identifier of the MEMORY BLOCK.
813#
814# @online: Whether the MEMORY BLOCK is enabled in guest.
815#
816# @can-offline: #optional Whether offlining the MEMORY BLOCK is possible.
817#               This member is always filled in by the guest agent when the
818#               structure is returned, and always ignored on input (hence it
819#               can be omitted then).
820#
821# Since: 2.3
822##
823{ 'struct': 'GuestMemoryBlock',
824  'data': {'phys-index': 'uint64',
825           'online': 'bool',
826           '*can-offline': 'bool'} }
827
828##
829# @guest-get-memory-blocks:
830#
831# Retrieve the list of the guest's memory blocks.
832#
833# This is a read-only operation.
834#
835# Returns: The list of all memory blocks the guest knows about.
836# Each memory block is put on the list exactly once, but their order
837# is unspecified.
838#
839# Since: 2.3
840##
841{ 'command': 'guest-get-memory-blocks',
842  'returns': ['GuestMemoryBlock'] }
843
844##
845# @GuestMemoryBlockResponseType
846#
847# An enumeration of memory block operation result.
848#
849# @success: the operation of online/offline memory block is successful.
850# @not-found: can't find the corresponding memoryXXX directory in sysfs.
851# @operation-not-supported: for some old kernels, it does not support
852#                           online or offline memory block.
853# @operation-failed: the operation of online/offline memory block fails,
854#                    because of some errors happen.
855#
856# Since: 2.3
857##
858{ 'enum': 'GuestMemoryBlockResponseType',
859  'data': ['success', 'not-found', 'operation-not-supported',
860           'operation-failed'] }
861
862##
863# @GuestMemoryBlockResponse:
864#
865# @phys-index: same with the 'phys-index' member of @GuestMemoryBlock.
866#
867# @response: the result of memory block operation.
868#
869# @error-code: #optional the error number.
870#               When memory block operation fails, we assign the value of
871#               'errno' to this member, it indicates what goes wrong.
872#               When the operation succeeds, it will be omitted.
873#
874# Since: 2.3
875##
876{ 'struct': 'GuestMemoryBlockResponse',
877  'data': { 'phys-index': 'uint64',
878            'response': 'GuestMemoryBlockResponseType',
879            '*error-code': 'int' }}
880
881##
882# @guest-set-memory-blocks:
883#
884# Attempt to reconfigure (currently: enable/disable) state of memory blocks
885# inside the guest.
886#
887# The input list is processed node by node in order. In each node @phys-index
888# is used to look up the guest MEMORY BLOCK, for which @online specifies the
889# requested state. The set of distinct @phys-index's is only required to be a
890# subset of the guest-supported identifiers. There's no restriction on list
891# length or on repeating the same @phys-index (with possibly different @online
892# field).
893# Preferably the input list should describe a modified subset of
894# @guest-get-memory-blocks' return value.
895#
896# Returns: The operation results, it is a list of @GuestMemoryBlockResponse,
897#          which is corresponding to the input list.
898#
899#          Note: it will return NULL if the @mem-blks list was empty on input,
900#          or there is an error, and in this case, guest state will not be
901#          changed.
902#
903# Since: 2.3
904##
905{ 'command': 'guest-set-memory-blocks',
906  'data':    {'mem-blks': ['GuestMemoryBlock'] },
907  'returns': ['GuestMemoryBlockResponse'] }
908
909# @GuestMemoryBlockInfo:
910#
911# @size: the size (in bytes) of the guest memory blocks,
912#        which are the minimal units of memory block online/offline
913#        operations (also called Logical Memory Hotplug).
914#
915# Since: 2.3
916##
917{ 'struct': 'GuestMemoryBlockInfo',
918  'data': {'size': 'uint64'} }
919
920##
921# @guest-get-memory-block-info:
922#
923# Get information relating to guest memory blocks.
924#
925# Returns: memory block size in bytes.
926# Returns: @GuestMemoryBlockInfo
927#
928# Since 2.3
929##
930{ 'command': 'guest-get-memory-block-info',
931  'returns': 'GuestMemoryBlockInfo' }
932