| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
To allow the server to send agent messages without needing to wait for a
self-token. IE for sending VD_AGENT_CLIENT_DISCONNECTED messages.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
| |
|
|
|
|
| |
The ref count is used in order to keep buffers that were in the write
queue and now are part of migration data, in case the char_device state
is destroyed before we complete sending the migration data.
|
| |
|
|
|
|
|
|
| |
might have changed since it was created
If reading/writing from the device have occured before migration data
has arrived, the migration data might no longer be relvant, and we
disconnect the client.
|
| | |
|
| |
|
|
| |
for migraion data
|
| | |
|
| |
|
|
|
|
|
| |
When restoring migration data, we also restore data that is addressed to
the device, and that might have been originated from more than 1
message. When the write buffer that is assoicated with this data is
released, we need to free all the relevant tokens.
|
| |
|
|
| |
The original definition is in spice.h
|
| |
|
|
| |
In addition, I also removed the no longer used wakeup callback
|
| |
|
|
|
|
|
|
| |
This patch and the following one do not introduce tokening to the
spicevmc channel. But this can be done easily later, by setting the appropriate
variables in SpiceCharDeviceState (after adding
the appropriate protocol messages, and implementing this in the client
side).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SpiceCharDeviceState manages the (1) write-to-device queue
(2) wakeup and reading from the device (3) client tokens (4)
sending messages from the device to the client/s, considering the
available tokens.
SpiceCharDeviceState can be also stopped and started. When the device
is stopped, no reading or writing is done from/to the device. Messages
addressed from the client to the device are being queued.
Later, an api for stop/start will be added to spice.h and it should
be called from qemu.
This patch does not yet remove the wakeup callback from
SpiceCharDeviceState, but once all the char devices (agent/spicevmc/smartcard)
code will switch to the new implementation, SpiceCharDeviceState
will be moved to the c file and its reference to the wakeup callback will be removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 usbredir.c to spicevmc.c and changes the prefix of all
functions / structs to match. This should make clear that the code is not
usbredir specific.
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, they must start at the SPICE_CHANNEL_USER_DEFINED_START value
(128).
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>
|
| | |
|
| |
|
