Add a new string message for sending proxy details.
CONTROLLER_PROXY (ControllerData, string)
The value must be of the form [protocol://]<host>[:port]
The proxy string may be specified with a protocol:// prefix to specify
alternative proxy protocols.
If no protocol is specified in the proxy string or if the string
doesn't match a supported one, the proxy will be treated as a HTTP
proxy.
Currently the agent expect a monitor config to be continuous. If the user has
3 monitors (3 spice display windows) open and tries to disable the 2nd one,
then instead of the 2nd one being closed, the 3th one ends up closed.
To be able to fix this we need to be able to send a sparse monitor config
to the agent. A monitor being disabled in such a sparse config is simply
represented by its width and height being 0 in its VDAgentMonConfig.
Since old versions of the agent won't be capable of dealing with such a
0x0 sized monitor, this patch adds a new VD_AGENT_CAP_SPARSE_MONITORS_CONFIG
capability to signal to the client that the agent understands this, and
the client should only send sparse monitor configs to agents with this
capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
At present, Vmware and Virtualbox has supported file drag&drop feature,
I think it's a good feature for users, so we want qemu/spice to
supports it.
This patch first adds communication protocol between client and guest,
we must make the agent protocol stable before coding, this is what we
want this patch to do.
This feature has been discussed on spice mailing list.
The more details are available at following pages:
http://lists.freedesktop.org/archives/spice-devel/2012-November/011400.html
and
http://lists.freedesktop.org/archives/spice-devel/2012-November/011485.html
Signed-off-by: Dunrong Huang <riegamaths@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Alon Levy <alevy@redhat.com>
Cc: Uri Lublin <uril@redhat.com>
The channel is based on Spicevmc which simply tunnels data between
client and server. A few messages have been added:
SPICE_MSG_PORT_INIT: Describes the port state and fqdn name, should be
sent only once when the client connects.
SPICE_MSG_PORT_EVENT: Server port event. SPICE_PORT_EVENT_OPENED and
SPICE_PORT_EVENT_CLOSED are typical values when the chardev is opened
or closed.
SPICE_MSGC_PORT_EVENT: Client port event.
(See related spice.proto change in spice-common)
So far we have used the agent to notify the guest of a request to change
the monitors configurations (heads) on the qxl device. This patch introduces
a new interrupt and new fields in the qxl rom to notify the guest about
a new request, similarly to how physical hardware notifies the driver.
We compute crc over the monitors configuration to avoid host-write from a
following update while guest-read corruption. The update protocol is:
qemu:
(2) fill QXLRom::client_monitors_config
(3) raise QXL_INTERRUPT_CLIENT_MONITORS_CONFIG
guest:
(1) clear QXL_INTERRUPT_CLIENT_MONITORS_CONFIG bit in irq status
(2) read QXLRom::client_monitors_config
(3) (verify-crc)? done : goto 2
If the interrupt mask is ~0 or 0, or does not have
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG set, we also assume it doesn't support
this interrupt.
The client_present field is a byte that is set of non-zero when a
client is connected and to zero when no client is connected.
The client_capabilities[58] array contains 464 bits that indicate the
capabilities of the client. Each bit corresponds to a
SPICE_DISPLAY_CAP_* capability. In particular, if the client has
capability C, then bit (C % 8) in byte (C / 8) is set. The capability
bits only have a defined meaning when a client is connected, ie., when
client_present is non-zero. The number 58 was chosen to fill out a
cache line in QXLRom.
A new QXL_INTERRUPT_CLIENT interrupt is defined, which will be raised
whenever a client connects or disconnects.
Even though the ability to handle a8 surfaces was added at the same
time as the composite command, they are logically separate, so add a
capability bit to indicate the presence of a8 surfaces.
Add a new arbitrary keyboard scancodes message.
For now, it will be used to avoid unwanted key repeatition when there
is jitter in the network and too much time between DOWN and UP
messages, instead the client will send the press & release scancode in
a sequence from a single message.
If the server doesn't support INPUTS_CAP_KEY_SCANCODE, the client is
responsible to handle a fallback mode with the exisiting KEY_DOWN and
KEY_UP messages.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=812347
The main difference between semi-seamless and seamless migration is that
while in semi-seamless migration the state of all the channels is
being completely reset after migration is complete, in seamless migration
the essential parts of the state are restored on the server side, and
are left the same on the client side. semi-seamless migration is
equivalent to having the client disconnect from the src and connected
from scratch to the dest, with the exception, that the handshake with
the dest server occurs before the client has disconnected from the src.
In semi-seamless migration in-flight data gets lost, e.g., a file
transfer to a usb device might be disrupted.
=======================
===protocol details====
=======================
Let s1, s2, and c be the src server, dest server and client, respectively.
Semi-Seamless migration protocol
================================
pre-migration phase:
--------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN
In response, c tries to establish a connection to s2. After the connection is
established, it is inactive (the client doesn't attempt to read or
write messages from/to it)
(2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED or
SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR
post migration phase:
---------------------
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_END or
SPICE_MSG_MAIN_MIGRATE_CANCEL
In case of the former, c disconnects from s1, resets all its
channels states and switches to an active connection with s2.
(2) c->s2: SPICE_MSGC_MAIN_MIGRATE_END
The msg signals that all the channels have been migrated successfully to s2.
Seamless migration protocol
===========================
pre-migration phase:
--------------------
In case qemu/libvirt/client do not support seamless migration,
s1 takes the semi-seamless pathway for migration. Otherwise:
(1) s1->c: SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS (*New*)
The msg includes the version of the migration protocol
of s1.
In response c tries to establish a connection to s2.
(2)
If the connection fails:
(2.1) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECT_ERROR
If s2 supports SPICE_MAIN_CAP_SEAMLESS_MIGRATE:
(2.2) c->s2: SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS (*New*)
The msg includes the version of the migration protocol
of s1. The msg is used for querying s2 if seamless migration
is possible, given the migration protocol version of s1.
(2.2.1) s2->c: SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK (*New*)
(2.2.2) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS (*New*) or
SPICE_MSGC_MAIN_MIGRATE_CONNECTED
The latter is sent when c receives SEAMLESS_NACK, and
indicates s1 to apply semi-seamless protocol on post
migraion phase.
If s2 does not support SPICE_MAIN_CAP_SEMI_SEAMLESS_MIGRATE:
(2.3) c->s1: SPICE_MSGC_MAIN_MIGRATE_CONNECTED
(see 2.2.2)
post migration phase:
---------------------
While the pre migration phase was conducted by the main channel, this
phase's protocol occurs in all the migrated channels.
(1) s1->c: SPICE_MSG_MIGRATE
The msg marks the client that the connection is paused from s1 side, and
next to this msg, the only possible msg s1 can send is
SPICE_MSG_MIGRATE_DATA
msg optional flags:
(a) MIGRATE_FLUSH_MARK
This flag is required for finalizing the channel connection
without losing any in-flight data.
This flag indicates that s1 expects SPICE_MSGC_MIGRATE_FLUSH_MARK,
for signaling that c will pause the connection and not send any more messages
to s1.
(b) MIGRATE_DATA
The flag indicates that c should receive from s1
SPICE_MSG_MIGRATE_DATA
(2) c->s1: SPICE_MSGC_MIGRATE_FLUSH_MARK (if required)
c pushes the msg to the head of its output msg queue,
and sends it before all its other pending msgs - they will be sent to s2
later.
(3) s1->c: SPICE_MSG_MIGRATE_DATA (if required)
The msg contains all the data that the server requires for restoring
the channel's state on s2 side correctly.
(4) c disconnects the channel from s1 and switches to an active connection
with s2.
(4) c->s2: SPICE_MSGC_MIGRATE_DATA
Similarly to SPICE_MSG_AGENT_CONNECTED, the msg notifies the main
channel about attaching an agent. In addition the msg also contains the
number of tokens allocated to the client.
This new command is intended to be used for implementing the Composite
request from the Render X extension. See
http://www.x.org/releases/current/doc/renderproto/renderproto.txt
for a description of the Render extension.
Composite has three fields: src, mask and destination, of which mask
is optional (can be NULL). There are also two pointers to
transformations, one for each of src and mask.
The command also has 32 bits of flags which indicates
- which compositing operator to use
- which filters to apply when sampling source and mask
- which repeat mode to apply when sampling source and mask
- whether the mask should be considered to have 'component alpha'
- whether the alpha channel of any of the images should be ignored.
The last one of these features is necessary because in the X protocol
an offscreen surface is simply a collection of bits with no visual
interpretation. In order for Render to use these bits, a wrapper
object is used that contains the pixel format. Since one offscreen
surface can be wrapped by multple objects, there is not a one-to-one
correspondence between pixel formats and surfaces.
In SPICE surfaces do have an associated pixel format, which means the
above feature of Render cannot be supported without adding a similar
concept to the wrapper object to the SPICE protocol. However, the most
common use for having multiple wrappers for one offscreen surface is
to interpret an alpha surface as not having an alpha channel or vice
versa.
Adds on device:
RAM
Header
monitors_config - pointer
QXLMonitorsConfig
count == n
max_allowed = N >= 0
QXLHead 1
...
QXLHead n
id, surface_id, x, y, width, height, flags
IO:
QXL_IO_MONITORS_CONFIG
server flushes command ring, then calls server callback for changing monitors config.
New revision to let the driver know about the new io:
QXL_REVISION_STABLE_V12=0x04,
Adds server/client capability:
SPICE_DISPLAY_CAP_MONITORS_CONFIG
Server message will be added in spice-server and spice-common.
Version is bumped to 0.12.0 to indicate new IO and structs
QXL_ESCAPE_SET_CUSTOM_DISPLAY is Windows specific message
to tell the display & miniport driver to update the mode
table with a custom resolution.
The mode table needs to be forcefully refreshed after
setting a custom display, it can be done by querying an
invalid/unknown mode:
EnumDisplaySettings(dev_name, 0xffffff, &tempDevMode);
rhbz #815422
Add SPICE_MSG_DISPLAY_STREAM_DATA_SIZED, for stream_data message
that in addition to the mjpeg data, also contains the
(1) width and height of the compressed frame.
(2) the destination box of the frame.
The server can send such messages only to clients with
SPICE_DISPLAY_CAP_SIZED_STREAM.
When playing a youtube video on Windows guest, the driver sometimes sends
images which contain the video frames, but also other parts of the
screen (e.g., the youtube process bar). In order to prevent glitches, we send these
images as part of the stream, using SPICE_MSG_DISPLAY_STREAM_DATA_SIZED.
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>
