+SRST
+``-object typename[,prop1=value1,...]``
+ Create a new object of type typename setting properties in the order
+ they are specified. Note that the 'id' property must be set. These
+ objects are placed in the '/objects' path.
+
+ ``-object memory-backend-file,id=id,size=size,mem-path=dir,share=on|off,discard-data=on|off,merge=on|off,dump=on|off,prealloc=on|off,host-nodes=host-nodes,policy=default|preferred|bind|interleave,align=align``
+ Creates a memory file backend object, which can be used to back
+ the guest RAM with huge pages.
+
+ The ``id`` parameter is a unique ID that will be used to
+ reference this memory region when configuring the ``-numa``
+ argument.
+
+ The ``size`` option provides the size of the memory region, and
+ accepts common suffixes, eg ``500M``.
+
+ The ``mem-path`` provides the path to either a shared memory or
+ huge page filesystem mount.
+
+ The ``share`` boolean option determines whether the memory
+ region is marked as private to QEMU, or shared. The latter
+ allows a co-operating external process to access the QEMU memory
+ region.
+
+ The ``share`` is also required for pvrdma devices due to
+ limitations in the RDMA API provided by Linux.
+
+ Setting share=on might affect the ability to configure NUMA
+ bindings for the memory backend under some circumstances, see
+ Documentation/vm/numa\_memory\_policy.txt on the Linux kernel
+ source tree for additional details.
+
+ Setting the ``discard-data`` boolean option to on indicates that
+ file contents can be destroyed when QEMU exits, to avoid
+ unnecessarily flushing data to the backing file. Note that
+ ``discard-data`` is only an optimization, and QEMU might not
+ discard file contents if it aborts unexpectedly or is terminated
+ using SIGKILL.
+
+ The ``merge`` boolean option enables memory merge, also known as
+ MADV\_MERGEABLE, so that Kernel Samepage Merging will consider
+ the pages for memory deduplication.
+
+ Setting the ``dump`` boolean option to off excludes the memory
+ from core dumps. This feature is also known as MADV\_DONTDUMP.
+
+ The ``prealloc`` boolean option enables memory preallocation.
+
+ The ``host-nodes`` option binds the memory range to a list of
+ NUMA host nodes.
+
+ The ``policy`` option sets the NUMA policy to one of the
+ following values:
+
+ ``default``
+ default host policy
+
+ ``preferred``
+ prefer the given host node list for allocation
+
+ ``bind``
+ restrict memory allocation to the given host node list
+
+ ``interleave``
+ interleave memory allocations across the given host node
+ list
+
+ The ``align`` option specifies the base address alignment when
+ QEMU mmap(2) ``mem-path``, and accepts common suffixes, eg
+ ``2M``. Some backend store specified by ``mem-path`` requires an
+ alignment different than the default one used by QEMU, eg the
+ device DAX /dev/dax0.0 requires 2M alignment rather than 4K. In
+ such cases, users can specify the required alignment via this
+ option.
+
+ The ``pmem`` option specifies whether the backing file specified
+ by ``mem-path`` is in host persistent memory that can be
+ accessed using the SNIA NVM programming model (e.g. Intel
+ NVDIMM). If ``pmem`` is set to 'on', QEMU will take necessary
+ operations to guarantee the persistence of its own writes to
+ ``mem-path`` (e.g. in vNVDIMM label emulation and live
+ migration). Also, we will map the backend-file with MAP\_SYNC
+ flag, which ensures the file metadata is in sync for
+ ``mem-path`` in case of host crash or a power failure. MAP\_SYNC
+ requires support from both the host kernel (since Linux kernel
+ 4.15) and the filesystem of ``mem-path`` mounted with DAX
+ option.
+
+ ``-object memory-backend-ram,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave``
+ Creates a memory backend object, which can be used to back the
+ guest RAM. Memory backend objects offer more control than the
+ ``-m`` option that is traditionally used to define guest RAM.
+ Please refer to ``memory-backend-file`` for a description of the
+ options.
+
+ ``-object memory-backend-memfd,id=id,merge=on|off,dump=on|off,share=on|off,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave,seal=on|off,hugetlb=on|off,hugetlbsize=size``
+ Creates an anonymous memory file backend object, which allows
+ QEMU to share the memory with an external process (e.g. when
+ using vhost-user). The memory is allocated with memfd and
+ optional sealing. (Linux only)
+
+ The ``seal`` option creates a sealed-file, that will block
+ further resizing the memory ('on' by default).
+
+ The ``hugetlb`` option specify the file to be created resides in
+ the hugetlbfs filesystem (since Linux 4.14). Used in conjunction
+ with the ``hugetlb`` option, the ``hugetlbsize`` option specify
+ the hugetlb page size on systems that support multiple hugetlb
+ page sizes (it must be a power of 2 value supported by the
+ system).
+
+ In some versions of Linux, the ``hugetlb`` option is
+ incompatible with the ``seal`` option (requires at least Linux
+ 4.16).
+
+ Please refer to ``memory-backend-file`` for a description of the
+ other options.
+
+ The ``share`` boolean option is on by default with memfd.
+
+ ``-object rng-builtin,id=id``
+ Creates a random number generator backend which obtains entropy
+ from QEMU builtin functions. The ``id`` parameter is a unique ID
+ that will be used to reference this entropy backend from the
+ ``virtio-rng`` device. By default, the ``virtio-rng`` device
+ uses this RNG backend.
+
+ ``-object rng-random,id=id,filename=/dev/random``
+ Creates a random number generator backend which obtains entropy
+ from a device on the host. The ``id`` parameter is a unique ID
+ that will be used to reference this entropy backend from the
+ ``virtio-rng`` device. The ``filename`` parameter specifies
+ which file to obtain entropy from and if omitted defaults to
+ ``/dev/urandom``.
+
+ ``-object rng-egd,id=id,chardev=chardevid``
+ Creates a random number generator backend which obtains entropy
+ from an external daemon running on the host. The ``id``
+ parameter is a unique ID that will be used to reference this
+ entropy backend from the ``virtio-rng`` device. The ``chardev``
+ parameter is the unique ID of a character device backend that
+ provides the connection to the RNG daemon.
+
+ ``-object tls-creds-anon,id=id,endpoint=endpoint,dir=/path/to/cred/dir,verify-peer=on|off``
+ Creates a TLS anonymous credentials object, which can be used to
+ provide TLS support on network backends. The ``id`` parameter is
+ a unique ID which network backends will use to access the
+ credentials. The ``endpoint`` is either ``server`` or ``client``
+ depending on whether the QEMU network backend that uses the
+ credentials will be acting as a client or as a server. If
+ ``verify-peer`` is enabled (the default) then once the handshake
+ is completed, the peer credentials will be verified, though this
+ is a no-op for anonymous credentials.
+
+ The dir parameter tells QEMU where to find the credential files.
+ For server endpoints, this directory may contain a file
+ dh-params.pem providing diffie-hellman parameters to use for the
+ TLS server. If the file is missing, QEMU will generate a set of
+ DH parameters at startup. This is a computationally expensive
+ operation that consumes random pool entropy, so it is
+ recommended that a persistent set of parameters be generated
+ upfront and saved.
+
+ ``-object tls-creds-psk,id=id,endpoint=endpoint,dir=/path/to/keys/dir[,username=username]``
+ Creates a TLS Pre-Shared Keys (PSK) credentials object, which
+ can be used to provide TLS support on network backends. The
+ ``id`` parameter is a unique ID which network backends will use
+ to access the credentials. The ``endpoint`` is either ``server``
+ or ``client`` depending on whether the QEMU network backend that
+ uses the credentials will be acting as a client or as a server.
+ For clients only, ``username`` is the username which will be
+ sent to the server. If omitted it defaults to "qemu".
+
+ The dir parameter tells QEMU where to find the keys file. It is
+ called "dir/keys.psk" and contains "username:key" pairs. This
+ file can most easily be created using the GnuTLS ``psktool``
+ program.
+
+ For server endpoints, dir may also contain a file dh-params.pem
+ providing diffie-hellman parameters to use for the TLS server.
+ If the file is missing, QEMU will generate a set of DH
+ parameters at startup. This is a computationally expensive
+ operation that consumes random pool entropy, so it is
+ recommended that a persistent set of parameters be generated up
+ front and saved.
+
+ ``-object tls-creds-x509,id=id,endpoint=endpoint,dir=/path/to/cred/dir,priority=priority,verify-peer=on|off,passwordid=id``
+ Creates a TLS anonymous credentials object, which can be used to
+ provide TLS support on network backends. The ``id`` parameter is
+ a unique ID which network backends will use to access the
+ credentials. The ``endpoint`` is either ``server`` or ``client``
+ depending on whether the QEMU network backend that uses the
+ credentials will be acting as a client or as a server. If
+ ``verify-peer`` is enabled (the default) then once the handshake
+ is completed, the peer credentials will be verified. With x509
+ certificates, this implies that the clients must be provided
+ with valid client certificates too.
+
+ The dir parameter tells QEMU where to find the credential files.
+ For server endpoints, this directory may contain a file
+ dh-params.pem providing diffie-hellman parameters to use for the
+ TLS server. If the file is missing, QEMU will generate a set of
+ DH parameters at startup. This is a computationally expensive
+ operation that consumes random pool entropy, so it is
+ recommended that a persistent set of parameters be generated
+ upfront and saved.
+
+ For x509 certificate credentials the directory will contain
+ further files providing the x509 certificates. The certificates
+ must be stored in PEM format, in filenames ca-cert.pem,
+ ca-crl.pem (optional), server-cert.pem (only servers),
+ server-key.pem (only servers), client-cert.pem (only clients),
+ and client-key.pem (only clients).
+
+ For the server-key.pem and client-key.pem files which contain
+ sensitive private keys, it is possible to use an encrypted
+ version by providing the passwordid parameter. This provides the
+ ID of a previously created ``secret`` object containing the
+ password for decryption.
+
+ The priority parameter allows to override the global default
+ priority used by gnutls. This can be useful if the system
+ administrator needs to use a weaker set of crypto priorities for
+ QEMU without potentially forcing the weakness onto all
+ applications. Or conversely if one wants wants a stronger
+ default for QEMU than for all other applications, they can do
+ this through this parameter. Its format is a gnutls priority
+ string as described at
+ https://gnutls.org/manual/html_node/Priority-Strings.html.
+
+ ``-object filter-buffer,id=id,netdev=netdevid,interval=t[,queue=all|rx|tx][,status=on|off][,position=head|tail|id=<id>][,insert=behind|before]``
+ Interval t can't be 0, this filter batches the packet delivery:
+ all packets arriving in a given interval on netdev netdevid are
+ delayed until the end of the interval. Interval is in
+ microseconds. ``status`` is optional that indicate whether the
+ netfilter is on (enabled) or off (disabled), the default status
+ for netfilter will be 'on'.
+
+ queue all\|rx\|tx is an option that can be applied to any
+ netfilter.
+
+ ``all``: the filter is attached both to the receive and the
+ transmit queue of the netdev (default).
+
+ ``rx``: the filter is attached to the receive queue of the
+ netdev, where it will receive packets sent to the netdev.
+
+ ``tx``: the filter is attached to the transmit queue of the
+ netdev, where it will receive packets sent by the netdev.
+
+ position head\|tail\|id=<id> is an option to specify where the
+ filter should be inserted in the filter list. It can be applied
+ to any netfilter.
+
+ ``head``: the filter is inserted at the head of the filter list,
+ before any existing filters.
+
+ ``tail``: the filter is inserted at the tail of the filter list,
+ behind any existing filters (default).
+
+ ``id=<id>``: the filter is inserted before or behind the filter
+ specified by <id>, see the insert option below.
+
+ insert behind\|before is an option to specify where to insert
+ the new filter relative to the one specified with
+ position=id=<id>. It can be applied to any netfilter.
+
+ ``before``: insert before the specified filter.
+
+ ``behind``: insert behind the specified filter (default).
+
+ ``-object filter-mirror,id=id,netdev=netdevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]``
+ filter-mirror on netdev netdevid,mirror net packet to
+ chardevchardevid, if it has the vnet\_hdr\_support flag,
+ filter-mirror will mirror packet with vnet\_hdr\_len.
+
+ ``-object filter-redirector,id=id,netdev=netdevid,indev=chardevid,outdev=chardevid,queue=all|rx|tx[,vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]``
+ filter-redirector on netdev netdevid,redirect filter's net
+ packet to chardev chardevid,and redirect indev's packet to
+ filter.if it has the vnet\_hdr\_support flag, filter-redirector
+ will redirect packet with vnet\_hdr\_len. Create a
+ filter-redirector we need to differ outdev id from indev id, id
+ can not be the same. we can just use indev or outdev, but at
+ least one of indev or outdev need to be specified.
+
+ ``-object filter-rewriter,id=id,netdev=netdevid,queue=all|rx|tx,[vnet_hdr_support][,position=head|tail|id=<id>][,insert=behind|before]``
+ Filter-rewriter is a part of COLO project.It will rewrite tcp
+ packet to secondary from primary to keep secondary tcp
+ connection,and rewrite tcp packet to primary from secondary make
+ tcp packet can be handled by client.if it has the
+ vnet\_hdr\_support flag, we can parse packet with vnet header.
+
+ usage: colo secondary: -object
+ filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 -object
+ filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 -object
+ filter-rewriter,id=rew0,netdev=hn0,queue=all
+
+ ``-object filter-dump,id=id,netdev=dev[,file=filename][,maxlen=len][,position=head|tail|id=<id>][,insert=behind|before]``
+ Dump the network traffic on netdev dev to the file specified by
+ filename. At most len bytes (64k by default) per packet are
+ stored. The file format is libpcap, so it can be analyzed with
+ tools such as tcpdump or Wireshark.
+
+ ``-object colo-compare,id=id,primary_in=chardevid,secondary_in=chardevid,outdev=chardevid,iothread=id[,vnet_hdr_support][,notify_dev=id][,compare_timeout=@var{ms}][,expired_scan_cycle=@var{ms}``
+ Colo-compare gets packet from primary\_inchardevid and
+ secondary\_inchardevid, than compare primary packet with
+ secondary packet. If the packets are same, we will output
+ primary packet to outdevchardevid, else we will notify
+ colo-frame do checkpoint and send primary packet to
+ outdevchardevid. In order to improve efficiency, we need to put
+ the task of comparison in another thread. If it has the
+ vnet\_hdr\_support flag, colo compare will send/recv packet with
+ vnet\_hdr\_len. Then compare\_timeout=@var{ms} determines the
+ maximum delay colo-compare wait for the packet.
+ The expired\_scan\_cycle=@var{ms} to set the period of scanning
+ expired primary node network packets.
+ If you want to use Xen COLO, will need the notify\_dev to
+ notify Xen colo-frame to do checkpoint.
+
+ we must use it with the help of filter-mirror and
+ filter-redirector.
+
+ ::
+
+ KVM COLO
+
+ primary:
+ -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
+ -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66
+ -chardev socket,id=mirror0,host=3.3.3.3,port=9003,server,nowait
+ -chardev socket,id=compare1,host=3.3.3.3,port=9004,server,nowait
+ -chardev socket,id=compare0,host=3.3.3.3,port=9001,server,nowait
+ -chardev socket,id=compare0-0,host=3.3.3.3,port=9001
+ -chardev socket,id=compare_out,host=3.3.3.3,port=9005,server,nowait
+ -chardev socket,id=compare_out0,host=3.3.3.3,port=9005
+ -object iothread,id=iothread1
+ -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0
+ -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out
+ -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0
+ -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,iothread=iothread1
+
+ secondary:
+ -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down script=/etc/qemu-ifdown
+ -device e1000,netdev=hn0,mac=52:a4:00:12:78:66
+ -chardev socket,id=red0,host=3.3.3.3,port=9003
+ -chardev socket,id=red1,host=3.3.3.3,port=9004
+ -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0
+ -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1
+
+
+ Xen COLO
+
+ primary:
+ -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown
+ -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66
+ -chardev socket,id=mirror0,host=3.3.3.3,port=9003,server,nowait
+ -chardev socket,id=compare1,host=3.3.3.3,port=9004,server,nowait
+ -chardev socket,id=compare0,host=3.3.3.3,port=9001,server,nowait
+ -chardev socket,id=compare0-0,host=3.3.3.3,port=9001
+ -chardev socket,id=compare_out,host=3.3.3.3,port=9005,server,nowait
+ -chardev socket,id=compare_out0,host=3.3.3.3,port=9005
+ -chardev socket,id=notify_way,host=3.3.3.3,port=9009,server,nowait
+ -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0
+ -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out
+ -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0
+ -object iothread,id=iothread1
+ -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0,notify_dev=nofity_way,iothread=iothread1
+
+ secondary:
+ -netdev tap,id=hn0,vhost=off,script=/etc/qemu-ifup,down script=/etc/qemu-ifdown
+ -device e1000,netdev=hn0,mac=52:a4:00:12:78:66
+ -chardev socket,id=red0,host=3.3.3.3,port=9003
+ -chardev socket,id=red1,host=3.3.3.3,port=9004
+ -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0
+ -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1
+
+ If you want to know the detail of above command line, you can
+ read the colo-compare git log.
+
+ ``-object cryptodev-backend-builtin,id=id[,queues=queues]``
+ Creates a cryptodev backend which executes crypto opreation from
+ the QEMU cipher APIS. The id parameter is a unique ID that will
+ be used to reference this cryptodev backend from the
+ ``virtio-crypto`` device. The queues parameter is optional,
+ which specify the queue number of cryptodev backend, the default
+ of queues is 1.
+
+ .. parsed-literal::
+
+ # |qemu_system| \
+ [...] \
+ -object cryptodev-backend-builtin,id=cryptodev0 \
+ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
+ [...]
+
+ ``-object cryptodev-vhost-user,id=id,chardev=chardevid[,queues=queues]``
+ Creates a vhost-user cryptodev backend, backed by a chardev
+ chardevid. The id parameter is a unique ID that will be used to
+ reference this cryptodev backend from the ``virtio-crypto``
+ device. The chardev should be a unix domain socket backed one.
+ The vhost-user uses a specifically defined protocol to pass
+ vhost ioctl replacement messages to an application on the other
+ end of the socket. The queues parameter is optional, which
+ specify the queue number of cryptodev backend for multiqueue
+ vhost-user, the default of queues is 1.
+
+ .. parsed-literal::
+
+ # |qemu_system| \
+ [...] \
+ -chardev socket,id=chardev0,path=/path/to/socket \
+ -object cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 \
+ -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 \
+ [...]
+
+ ``-object secret,id=id,data=string,format=raw|base64[,keyid=secretid,iv=string]``
+ \
+ ``-object secret,id=id,file=filename,format=raw|base64[,keyid=secretid,iv=string]``
+ Defines a secret to store a password, encryption key, or some
+ other sensitive data. The sensitive data can either be passed
+ directly via the data parameter, or indirectly via the file
+ parameter. Using the data parameter is insecure unless the
+ sensitive data is encrypted.
+
+ The sensitive data can be provided in raw format (the default),
+ or base64. When encoded as JSON, the raw format only supports
+ valid UTF-8 characters, so base64 is recommended for sending
+ binary data. QEMU will convert from which ever format is
+ provided to the format it needs internally. eg, an RBD password
+ can be provided in raw format, even though it will be base64
+ encoded when passed onto the RBD sever.
+
+ For added protection, it is possible to encrypt the data
+ associated with a secret using the AES-256-CBC cipher. Use of
+ encryption is indicated by providing the keyid and iv
+ parameters. The keyid parameter provides the ID of a previously
+ defined secret that contains the AES-256 decryption key. This
+ key should be 32-bytes long and be base64 encoded. The iv
+ parameter provides the random initialization vector used for
+ encryption of this particular secret and should be a base64
+ encrypted string of the 16-byte IV.
+
+ The simplest (insecure) usage is to provide the secret inline
+
+ .. parsed-literal::
+
+ # |qemu_system| -object secret,id=sec0,data=letmein,format=raw
+
+ The simplest secure usage is to provide the secret via a file
+
+ # printf "letmein" > mypasswd.txt # QEMU\_SYSTEM\_MACRO -object
+ secret,id=sec0,file=mypasswd.txt,format=raw
+
+ For greater security, AES-256-CBC should be used. To illustrate
+ usage, consider the openssl command line tool which can encrypt
+ the data. Note that when encrypting, the plaintext must be
+ padded to the cipher block size (32 bytes) using the standard
+ PKCS#5/6 compatible padding algorithm.
+
+ First a master key needs to be created in base64 encoding:
+
+ ::
+
+ # openssl rand -base64 32 > key.b64
+ # KEY=$(base64 -d key.b64 | hexdump -v -e '/1 "%02X"')
+
+ Each secret to be encrypted needs to have a random
+ initialization vector generated. These do not need to be kept
+ secret
+
+ ::
+
+ # openssl rand -base64 16 > iv.b64
+ # IV=$(base64 -d iv.b64 | hexdump -v -e '/1 "%02X"')
+
+ The secret to be defined can now be encrypted, in this case
+ we're telling openssl to base64 encode the result, but it could
+ be left as raw bytes if desired.
+
+ ::
+
+ # SECRET=$(printf "letmein" |
+ openssl enc -aes-256-cbc -a -K $KEY -iv $IV)
+
+ When launching QEMU, create a master secret pointing to
+ ``key.b64`` and specify that to be used to decrypt the user
+ password. Pass the contents of ``iv.b64`` to the second secret
+
+ .. parsed-literal::
+
+ # |qemu_system| \
+ -object secret,id=secmaster0,format=base64,file=key.b64 \
+ -object secret,id=sec0,keyid=secmaster0,format=base64,\
+ data=$SECRET,iv=$(<iv.b64)
+
+ ``-object sev-guest,id=id,cbitpos=cbitpos,reduced-phys-bits=val,[sev-device=string,policy=policy,handle=handle,dh-cert-file=file,session-file=file]``
+ Create a Secure Encrypted Virtualization (SEV) guest object,
+ which can be used to provide the guest memory encryption support
+ on AMD processors.
+
+ When memory encryption is enabled, one of the physical address
+ bit (aka the C-bit) is utilized to mark if a memory page is
+ protected. The ``cbitpos`` is used to provide the C-bit
+ position. The C-bit position is Host family dependent hence user
+ must provide this value. On EPYC, the value should be 47.
+
+ When memory encryption is enabled, we loose certain bits in
+ physical address space. The ``reduced-phys-bits`` is used to
+ provide the number of bits we loose in physical address space.
+ Similar to C-bit, the value is Host family dependent. On EPYC,
+ the value should be 5.
+
+ The ``sev-device`` provides the device file to use for
+ communicating with the SEV firmware running inside AMD Secure
+ Processor. The default device is '/dev/sev'. If hardware
+ supports memory encryption then /dev/sev devices are created by
+ CCP driver.
+
+ The ``policy`` provides the guest policy to be enforced by the
+ SEV firmware and restrict what configuration and operational
+ commands can be performed on this guest by the hypervisor. The
+ policy should be provided by the guest owner and is bound to the
+ guest and cannot be changed throughout the lifetime of the
+ guest. The default is 0.
projects / qemu.git / blobdiff