This allows a client to identify a Spice server. This can be useful to
associate data/configuration with this particular server.
The corresponding main channel messages are:
message {
uint8 uuid[16];
} uuid;
message {
uint32 name_len;
uint8 name[name_len] @end @nomarshal; \* \0 terminated *\
} name;
Those messages are sent by the server only if the capability
SPICE_MAIN_CAP_NAME_AND_UUID is available on the client, and the
server has the relevant data.
-Add SpiceMiniDataHeader.
-Introduce capability SPICE_COMMON_CAP_MINI_HEADER.
The advantage of using a header without sub list is to spare the 4 bytes that were sent
for a lot of messages without sublist.
Instead, messages that previously contained sub lists, will be split to two msgs.
The first one will be SPICE_MSG_LIST, holding the sub list, and the second will be the
main msg.
When most of the messages do not contain sub lists, the overhead of the additional 10 bytes
for the header of SPICE_MSG_LIST is negligible. In addition, if there is
only one message in the list, it can be sent independently.
Instead of sending the serial number of the messages, the client and
the server will increment local counters upon sending/receiving a
message.
- enums.h was generated from spice.proto
* as a result SPICE_CHANNEL_USER_DEFINED_START, which was added
manually, was removed. It is not used yet. If it is going to be used it
can be added to protocol.h in the future.
- The new msg body is SpiceSubMessageList
From SHM_OPEN(3):
For portable use, a shared memory object should be identified by a name
of the form /somename; that is, a null-terminated string of up to
NAME_MAX (i.e., 255) characters consisting of an initial slash,
followed by one or more characters, none of which are slashes.
While discussing various things with Alon in Vancouver, it came up that
having a channel which simply passes through data coming out of a qemu
chardev frontend unmodified, like the usbredir channel does, can be used
for a lot of other cases too. To facilitate this the usbredir channel code
will be turned into a generic spicevmc channel, which is just a passthrough
to the client, from the spicevmc chardev.
This patch renames the msg types to make clear that they are not usbredir
specific, but instead are generic spicevmc data passthrough messages. The
usbredir channel id is unmodified by this, although the same code and
messages can now be used for multiple purposes, we still need unique ids
for each purpose, so that the client knows how to interpret / represent the
passed through data.
Some examples of why having a generic spicevmc pass through is good:
1) We could add a monitor channel, allowing access to the qemu monitor from
the spice client, since the monitor is a chardev frontend we could re-use
the generic spicevmc channel server code, so all that is needed to add this
(server side) would be reserving a new channel id for this.
2) We could allow users to come up with new channels of their own, without
requiring qemu or server modification. The idea is to allow doing something
like this on the qemu startup cmdline:
-chardev spicevmc,name=generic,channelid=128
To ensure these new "generic" channels cannot conflict with newly added
official types, the must start at the SPICE_CHANNEL_USER_DEFINED_START value
this patch adds (128 or higher).
These new user defined channels could then either be used with a special
modified client, with client plugins (if we add support for those), or
by exporting them on the client side for use by an external ap, see below.
3) We could also add support to the client to make user-defined channels
end in a unix socket / pipe, allowing handling of the data by an external app,
we could for example have a new spice client cmdline argument like this:
--custom-channel unixsocket=/tmp/mysocket,channelid=128
This would allow for something like:
$random app on guest -> virtio-serial -> spicevmc chardev ->
-> spicevmc channel -> unix socket -> $random app on client
4) On hind sight this could also have been used for the smartcard stuff,
with a 1 channel / reader model, rather then the current multiplexing code
where we've our own multiplexing protocol wrapper over the libcacard
smartcard protocol.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The driver will check for this revision or higher to know that the device
supports async io, the two S3 related ios, and the interrupts IO_CMD and ERROR.
related RHBZ: 688883
Guest initiated sleep looks like this:
Guest:
(0) stop putting new commands into the rings
(1) QXL_IO_FLUSH_SURFACES
qxl calls flush_surfaces(), spice-server flushes command rings and
renders all surfaces, thereby flushing state to device memory.
(2) QXL_IO_DESTROY_ALL_SURFACES
zap surfaces
(3) QXL_IO_FLUSH_RELEASE
push release queue head into the release ring, so the guest
will see it and can release everything.
(4) tell acpi to reset
Qemu:
(5) qxl_reset_handler
Guest:
(6) sends surface create commands
The QXL_IO_FLUSH_SURFACES is an optimization, to reduce vmexits. It is used to
flush both command rings and update all surfaces at once (equivalent to
UPDATE_AREA X NUM_ACTIVE_SURFACES)
destroy all surfaces to release resources but not destroy the guest side surfaces
get device to flush all server released resources to the release ring (could use multiple
calls to OOM - but this is not well defined, would need to loop)
After (1) there will be no memory allocated on the pci bars.
Add async versions of the I/O commands which do not block and instead
raise the new QXL_INTERRUPT_IO_CMD when done.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
These changes the protocol the following way:
When the client announces it has SPICE_PLAYBACK_CAP_VOLUME, the server
can send PlaybackChannel.{volume,mute} messages to notify of volume
changes (respectively for RECORD).
If the client doesn't implement SPICE_PLAYBACK_CAP_VOLUME, the server can
handle the volume changes the way it prefers, for example, ignoring them or
applying volume effect on the server side etc..
needed for spice/common files used by the client, server & qxl driver.
in windows _inline works for both c/c++, while inline is c++ only.
compiling the client with mixed c/c++ code required this define.
spice-protocol comes with 2 headers to handle structure packing,
but controller_prot.h and foreign_menu_prot were both using their
own preprocessor definitions to handle packing. It's better to have
structure packing macros centralized since how it's done varies
between compilers, so it may need to change over time.
Add a new capability VD_AGENT_CAP_CLIPBOARD_SELECTION.
When both client and servers have this capability, the
VDAgentClipboard* messages MUST be prepended with a uint8_t indicating
which clipboard selection to operate + 3 bytes stuffing for alignment
that could be used for future capabilities or extensions.
A few clipboard selection are defined according to X11/Gtk scheme:
- VD_AGENT_CLIPBOARD_SELECTION_CLIPBOARD: the default clipboard,
implemented by most OS to deal with explicit Copy/Paste operations.
- VD_AGENT_CLIPBOARD_SELECTION_PRIMARY: the PRIMARY clipboard, used
for mouse selections.
- VD_AGENT_CLIPBOARD_SELECTION_SECONDARY: the SECONDARY clipboard.
See also:
http://www.freedesktop.org/wiki/Specifications/ClipboardsWikihttps://bugs.freedesktop.org/show_bug.cgi?id=34833
Current version 2.0 of the SPICE protocol describes how the client
reply to the server SpiceLinkReply message with a RSA_public_encrypt()
of the password.
Instead of using the current Spice AUTH mechanism, we would like to
offer different AUTH mechanisms, in particular SASL, which is a
framework allowing different underlying mechanisms such as
GSSAPI/Kerberos v5 (and optionally adding a data security layer).
We could bump the protocol version, but that would make this feature
mandatory for the implementer of the protocol. By using the channel
caps, the client and server are left to negotiate and alter the AUTH
part of the protocol as follows:
- SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION, if set, the authentication
mechanism can be chosen during link phase. If both client and server
have this cap, the client MUST reply to SpiceLinkReply with a
SpiceLinkAuthMechanism message, with the value of the CAP_AUTH
mechanism choosen (a uint32 auth_mechanism). The following
authentication steps are described by the selected authentication
mechanism.
The differents mechanisms selectable via
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION are also specified as part of
the common channel caps. They can be used only if both client and
server offer them.
Ex: no AUTH selection
C: SpiceLinkMess
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION not in common caps
- The client can't choose AUTH, and fallback on Spice RSA mechanism
Ex: AUTH selection
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism (with a matching CAP_AUTH)
- SPICE_COMMON_CAP_AUTH_SPICE, the following steps and authentication
mechanism are the same as with version 2.0: a RSA_public_encrypt()
of the password is sent.
This mechanism MUST be implemented in both client and server to
comply with the SPICE protocol.
- SPICE_COMMON_CAP_AUTH_SASL, the authentication exchange follows
SASL protocol has defined in RFC 2222.
This mechanism is OPTIONAL in both client and servers.
Ex: AUTH selection, followed by SASL authentication
AUTH Selection:
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism CAP_AUTH_SASL
Init:
S: u32 mechlist-length
u8-array mechlist-string
Start:
C: u32 mechname-length
u8-array mechname-string
u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
Step: (while continue)
C: u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
See also VNC SASL protocol description, which uses the same protocol:
http://sourceforge.net/mailarchive/forum.php?thread_name=20100719125155.GA14166%40evileye.atkac.brq.redhat.com&forum_name=tigervnc-rfbproto
Updated since v1 of this commit:
- renamed s/SPICE_CHANNEL_CAP/SPICE_COMMON_CAP
- added some note about mandatory vs optional mechanisms.
Current version 2.0 of the SPICE protocol describes how the client
reply to the server SpiceLinkReply message with a RSA_public_encrypt()
of the password.
Instead of using the current Spice AUTH mechanism, we would like to
offer different AUTH mechanisms, in particular SASL, which is a
framework allowing different underlying mechanisms such as
GSSAPI/Kerberos v5 (and optionally adding a data security layer).
We could bump the protocol version, but that would make this feature
mandatory for the implementer of the protocol. By using the channel
caps, the client and server are left to negotiate and alter the AUTH
part of the protocol as follows:
- SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION, if set, the authentication
mechanism can be chosen during link phase. If both client and server
have this cap, the client MUST reply to SpiceLinkReply with a
SpiceLinkAuthMechanism message, with the value of the CAP_AUTH
mechanism choosen (a uint32 auth_mechanism). The following
authentication steps are described by the selected authentication
mechanism.
The differents mechanisms selectable via
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION are also specified as part of
the common channel caps. They can be used only if both client and
server offer them.
Ex: no AUTH selection
C: SpiceLinkMess
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION not in common caps
- The client can't choose AUTH, and fallback on Spice RSA mechanism
Ex: AUTH selection
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism (with a matching CAP_AUTH)
- SPICE_COMMON_CAP_AUTH_SPICE, the following steps and authentication
mechanism are the same as with version 2.0: a RSA_public_encrypt()
of the password is sent.
This mechanism MUST be implemented in both client and server to
comply with the SPICE protocol.
- SPICE_COMMON_CAP_AUTH_SASL, the authentication exchange follows
SASL protocol has defined in RFC 2222.
This mechanism is OPTIONAL in both client and servers.
Ex: AUTH selection, followed by SASL authentication
AUTH Selection:
C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
- The client MUST reply with SpiceLinkAuthMechanism
C: SpiceLinkAuthMechanism CAP_AUTH_SASL
Init:
S: u32 mechlist-length
u8-array mechlist-string
Start:
C: u32 mechname-length
u8-array mechname-string
u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
Step: (while continue)
C: u32 clientout-length
u8-array clientout-string
S: u32 serverin-length
u8-array serverin-string
u8 continue
See also VNC SASL protocol description, which uses the same protocol:
http://sourceforge.net/mailarchive/forum.php?thread_name=20100719125155.GA14166%40evileye.atkac.brq.redhat.com&forum_name=tigervnc-rfbproto
Updated since v1 of this commit:
- renamed s/SPICE_CHANNEL_CAP/SPICE_COMMON_CAP
- added some note about mandatory vs optional mechanisms.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Ex: G_STRUCT_OFFSET(SpiceLinkReply, num_channel_caps) is 172 bytes
when compiled with -mms-bitfield, and 170 bytes without.
GLib/Gtk are compiled with -mms-bitfield, and it is necessary to
compile with the same option for compatibility. The pack pragma
for MINGW32 corrects the structure alignement.
We could use the pack pragma for GNUC unconditionally, that could help
to ensure struct binary compatibility between different compiled
flavours.
We are making all text send over the controller socket utf-8, rather then
having somethings as 8 bit (hostname) and others unicode16.
Adjust the CONTROLLER_MENU_*_DELIMITER defines for this.
