summaryrefslogtreecommitdiffstats
path: root/server/smartcard.c
Commit message (Collapse)AuthorAgeFilesLines
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-221-0/+1
|
* smartcard.c: avoid marshalling migration data with reference to a memory ↵Yonit Halperin2012-11-261-1/+1
| | | | | | | | | that might be released before send has completed The current solution just copy the buffer. Currently data that is read from the guest is always copied before sending it to the client. When we will have ref count for these buffers, we can also use it for marshalling the migration data.
* red_channel: remove unused migrate flag from RedChannelYonit Halperin2012-08-271-1/+0
| | | | The relevant flags reside in RedChannelClient and RedClient
* char_device: don't connect a migrated client if the state of the device ↵Yonit Halperin2012-08-271-7/+15
| | | | | | | | 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.
* smartcard: restore state after migration from migration dataYonit Halperin2012-08-271-7/+75
|
* smartcard migration: send migration dataYonit Halperin2012-08-271-5/+51
|
* smartcard: send MSG_MIGRATE upon vm migration completionYonit Halperin2012-08-271-5/+0
| | | | | The above is the default behaviour for red_channel_client, if client_cbs.migrate is not registered as part of red_channel_register_client_cbs
* smartcard: fix PIPE_ITEMs enum indexingYonit Halperin2012-08-271-1/+1
| | | | | The enum should start from PIPE_ITEM_TYPE_CHANNEL_BASE, otherwise, PIPE_ITEM_TYPE_ERROR is handled like PIPE_ITEM_TYPE_SET_ACK.
* smartcard: change the timing of attaching a client to SpiceCharDeviceStateYonit Halperin2012-08-271-45/+75
| | | | | | | | | Attach/detach a client to a SpiceCharDeviceState upon its connection/disconnection, instead of upon reader_add/remove messages. When the client is removed from a SpiceCharDeviceState, all the messages from this client are removed from the device write queue. This shouldn't happen when we only receive reader_remove and the client is still connected.
* char device migration: don't read or write from/to the device while waiting ↵Yonit Halperin2012-08-271-1/+2
| | | | for migraion data
* red_channel: handle sending SPICE_MSG_MIGRATEYonit Halperin2012-08-271-1/+3
| | | | | | | The relevant code is common to all channels. The patch also contains a fix to the return value for handle_migrate_data callback: s/uint64_t/int
* smartcard: Remove redefinition of typedef 'SmartCardDeviceState'Yonit Halperin2012-07-041-2/+2
|
* smartcard: use SpiceCharDeviceState for writing to the guest deviceYonit Halperin2012-07-031-22/+93
| | | | | | With SpiceCharDeviceState, the smartcard code now supports partial writes, and storing data that is received from the client after the device is stopped, instead of attempting to write it to the guest.
* smartcard: creating SmartCardChannelClient typeYonit Halperin2012-07-031-50/+56
| | | | | | | | | | | | | | The lifetime of the channel is not necessarily correlated to the life time of the device. In the next patch, we need to keep a reference to SpiceCharDeviceWriteBuffer, which might be in use even if the SpiceCharDeviceState is destroyed, but the channel is still connected. The next patch keeps this reference inside SmartCardChannelClient. This patch also removes the routine smartcard_readers_detach_all(rcc), which is unnecessary since we don't support multiple readers; even when we do support them, each channel client should be associated with only one reader (i.e., we will have different channels for different readers).
* smartcard: use SpiceCharDeviceState for managing reading from the deviceYonit Halperin2012-07-031-41/+127
| | | | | | | This patch and the following one do not introduce tokening to the smartcard 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).
* smartcard: fix an error messageYonit Halperin2012-07-031-1/+1
|
* smartcard: fix calc of remaining data size when reading more than one msg ↵Yonit Halperin2012-07-031-1/+1
| | | | from the device
* server: handle red_channel_client_create returning NULLYonit Halperin2012-05-211-0/+3
|
* VSCMsgHeader.reader_id is unsigned, so don't check for >= 0Daniel P. Berrange2012-04-251-2/+1
| | | | | | | * server/smartcard.c: Fix assertion to not check for >= 0 on unsigned variable Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Convert cases of () to (void)Daniel P. Berrange2012-04-251-4/+4
| | | | | | * server/reds.c, server/smartcard.c: s/()/(void) Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Use the spice-common logging functionsMarc-André Lureau2012-03-251-12/+12
| | | | | It will abort by default for critical level messages. That behaviour can be tuned at runtime.
* Use the spice-common submoduleMarc-André Lureau2012-03-251-5/+5
| | | | | | | | | | | | | | | | | | This patch will replace the common/ directory with the spice-common project. It is for now a simple project subdirectory shared with spice-gtk, but the goal is to make it a proper library later on. With this change, the spice-server build is broken. The following commits fix the build, and have been seperated to ease the review. v2 - moves all the generated marshallers to spice-common library - don't attempt to fix windows VS build, which should somehow be splitted with spice-common (or built from tarball only to avoid generation tools/libs deps) v3 - uses libspice-common-client - fix a mutex.h inclusion reported by Alon
* Ensure all members of ChannelCbs and ClientCbs are either assigned or NULLHans de Goede2012-03-101-5/+2
| | | | | | | | | | | | | | | While git-bisecting another issue I ended up hitting and not recognizing the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb. While fixing this (again) I noticed that (even after the fix) not all users of ChannelCbs first zero it. So this patch ensures that all users of ChannelCbs first zero it, and does the same for ClientCbs while at it. Since before this patch there were multiple zero-ing styles, some using memset and other using a zero initializer this patch also unifies all the zero-ing to use a NULL initializer for the first element. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Rewrite code to avoid triggering warning about casting param to free()Daniel P. Berrange2012-01-131-1/+2
| | | | | | | | Since free() takes a void* parameters do not need to be cast. The existing code here is actally fine, but it trips up the syntax-check rule, so tweak it to an equivalent construct which passes the syntax check
* smartcard handling: Fix compilation when ASSERT-s are turned onHans de Goede2012-01-131-1/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: Limit the access to SpiceDataHeader of messages - only via red_channel.Yonit Halperin2012-01-121-7/+11
|
* server: set & test channel capabilities in red_channelYonit Halperin2011-11-021-1/+3
| | | | | | | The code for setting and testing channel capabilities was unnecessarily duplicated. Now it is in red_channel. RedsChannel was dropped from Reds; It was used only for holding the channels common capabilities, which are now held in RedChannel.
* fix more inverted memset parametersHans de Goede2011-08-251-3/+3
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-231-49/+40
| | | | | | | | | | | | | | | | | | | | | | | Merging the functionality of reds::channel, into RedChannel. In addition, cleanup and fix disconnection code: before this patch, red_dispatcher_disconnect_display_client could have been called from the red_worker thread (and it must be called only from the io thread). RedChannel holds only connected channel clients. RedClient holds all the channel clients that were created till it is destroyed (and then it destroys them as well). Note: snd_channel still doesn't use red_channel, however it creates dummy channel and channel clients, in order to register itself in reds. server/red_channel.c: a channel is connected if it holds at least one channel client Previously I changed RedChannel to hold only connected channel clients and RedClient, to hold all the channel clients as long as it is not destroyed. usbredir: multichannel has not been tested, it just compiles.
* server/red_channel.c: pack all channel callbacks to ChannelCbsYonit Halperin2011-08-231-10/+10
|
* server/smartcard: support multiple clientsAlon Levy2011-08-231-34/+46
| | | | | | | | | each client supplying a smartcard channel gets it's own smartcard. If there are not enough smartcards provided by the server (read: qemu) then it will be as though there are none. currently disabled - later patches that enable smartcard don't make this channel available to any but the first client.
* server: Add RedClientAlon Levy2011-08-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That means RedClient tracks a ring of channels. Right now there will be only a single client because of the disconnection mechanism - whenever a new client comes we disconnect all existing clients. But this patch adds already a ring of clients to reds.c (stored in RedServer). There is a known problem handling many connections and disconnections at the same time, trigerrable easily by the following script: export NEW_DISPLAY=:3.0 Xephyr $NEW_DISPLAY -noreset & for ((i = 0 ; i < 5; ++i)); do for ((j = 0 ; j < 10; ++j)); do DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests & done sleep 2; done I fixed a few of the problems resulting from this in the same patch. This required already introducing a few other changes: * make sure all removal of channels happens in the main thread, for that two additional dispatcher calls are added to remove a specific channel client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT). * change some asserts in input channel. * make main channel disconnect not recursive * introduce disconnect call back to red_channel_create_parser The remaining abort is from a double free in the main channel, still can't find it (doesn't happen when running under valgrind - probably due to the slowness resulting from that), but is easy to see when running under gdb.
* server: move pipe from RedChannel to RedChannelClientAlon Levy2011-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Another cleanup patch, no change to behavior (still one client, and it disconnects previous client if any). The implementation for multiple client is straightforward: the pipe remains per (channel,client) pair, so it needs to move from the RedChannel that to RedChannelClient. Implementation using a single pipe with multiple consumers (to reflect different latencies) doesn't fit well with pipe rewriting that is used by the display channel. Additionally this approach is much simpler to verify. Lastly it doesn't add considerable overhead (but see the display channel changes in a later patch for a real place to rethink). This patch is just technical, changing signatures to reflect the first argument (oop style) so red_channel becomes red_channel_client. Some places may seem odd but they should be fixed with later comits where the channels grow to support multiple clients. Sound (playback/record) channels are the only ones not touched - this is consistent with previous patches, since they have been left out of the RedChannel refactoring. That is left as future work. (note that they don't use a pipe, which was the reason for not refactoring).
* server/red_channel (all): introduce RedChannelClientAlon Levy2011-08-231-74/+73
| | | | | | | | | | | | | | | | | | | | | This commit adds a RedChannelClient that now owns the stream connection, but still doesn't own the pipe. There is only a single RCC per RC right now (and RC still means RedChannel, RedClient will be introduced later). All internal api changes are in server/red_channel.h, hence the need to update all channels. red_worker.c is affected the most because it makes use of direct access to some of RedChannel still. API changes: 1. red_channel_client_create added. rec_channel_create -> (red_channel_create, red_channel_client_create) 2. two way connection: rcc->channel, channel->rcc (later channel will hold a list, and there will be a RedClient to hold the list of channels per client) 3. seperation of channel disconnect and channel_client_disconnect TODO: usbredir added untested.
* server/smartcard: fix smartcard_channel_send_errorAlon Levy2011-07-221-25/+8
| | | | | | | | It was sending the wrong data, the memory right after the VCSMsgHeader which was actually not where the data was. Fixed by having the header and data (VSCError, 4 bytes of the error code) embedded in the ErrorItem pipe item.
* server/smartcard: register channel only when hardware is availableAlon Levy2011-07-051-2/+9
|
* Revert "server/smartcard: don't register the channel if no hardware emulated"Alon Levy2011-06-291-4/+1
| | | | | | | | This reverts commit 456ff9f8d5d27ac763e89e67a100661084695dc5. That patch just disabled the smartcard channel completely because the check was done *before* the initialization of the qemu smartcard devices, not after.
* server/smartcard: don't register the channel if no hardware emulatedAlon Levy2011-06-231-1/+4
|
* server/smartcard: handle BaseChannel messagesAlon Levy2011-06-231-0/+6
| | | | | | According to spice.proto the smartcard channel can receive acks and any other message defined in BaseChannel. While the spicec implementation didn't send an ACK spice-gtk does, so handle it.
* server/smartcard: fix use after freeAlon Levy2011-05-241-1/+1
|
* add #include <config.h> to all source filesChristophe Fergeau2011-05-031-0/+4
| | | | | | | | When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
* add missing "LGPLv2.1 or later" header to source filesChristophe Fergeau2011-05-021-0/+17
|
* use foo(void) instead of foo() in prototypesChristophe Fergeau2011-05-021-1/+1
| | | | | In C, the latter isn't a prototype for a function with no arg, but declares a function with an undefined number of args.
* server/red_channel (+): remove red_channel_add_bufAlon Levy2011-03-021-13/+15
|
* server/red_channel (all): handle MIGRATE_DATA and MIGRATE_FLUSH_DATAAlon Levy2011-03-021-1/+4
| | | | | | | | | | Handling done in red_channel instead of per channel, using call backs for the channel specific part. Intended to reduce furthur reliance of channels on RedChannel struct. The commit makes the code harder to understand because of the artificial get_serial stuff, should later be fixed by having a joint migration header with the serial (since all channels pass it).
* server/red_channel (all): makes red_channel_reset_send_data privateAlon Levy2011-03-021-1/+0
| | | | ready the way for handling ack messages in RedChannel.
* server/red_channe: make hold_item take a channel argAlon Levy2011-03-021-1/+1
|
* server: rename s/peer/streamMarc-André Lureau2011-02-281-2/+2
| | | | | | | | This is stylish change again. We are talking about a RedStream object, so let's just name the variable "stream" everywhere, to avoid confusion with a non existent RedPeer object. https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: s/RedsStreamContext/RedsStreamMarc-André Lureau2011-02-271-1/+1
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server/smartcard: don't push our own error on reader addAlon Levy2011-02-091-3/+3
| | | | | | | | | | | | | | The device already sends one. There are actually two connections going on: server to client - this is the smartcard channel, it reuses the VSC protocol. server to device - this is an internal connection using VSC too. We generally just passthrough all messages from the client to the device, and from the device to the client. We only rewrite the reader_id because the device knows about a single id (it is actually a card id), and we may manage more then one in the future. Bottom line is that there was an extra VSC_Error message reaching the client.
generated by cgit (git 2.34.1) at 2024-05-02 22:48:55 +0000