If the guest supports client monitors config we pass it the
VDAgentMonitorsConfig message via the
QXLInterface::client_monitors_config api instead of via the vdagent.
Adds two functions:
- red_dispatcher_use_client_monitors_config:
check that QXLInterface supports client_monitors_config and that it's
functional.
- red_dispatcher_client_monitors_config:
send the client monitors configuration to the guest.
Used to implement guest monitor configuration change similarly to real
hardware in conjunction with the new qemu interrupt
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG. client_monitors_config is also
used to probe the support by the interface. If it is not supported we
send the message to the guest agent.
This makes a linux qxl driver similar to existing kms drivers.
The logic is:
For every received VDAgentMonitorsConfig:
if client_monitors_config(NULL):
write client configuration to pci rom BAR.
send interrupt to guest
guest kernel reads configuration from rom BAR.
guest kernel issues event to user space
user space reads (libdrm) and reconfigures (libXRandr)
else: (current implementation)
write message to guest agent
guest agent issues reconfiguration via XRandr / windows Escape ioctl to kernel
The following patch enables it to build on ARM platforms that support
atomics. Tested on an armv7hl on an ARMv7 device running Fedora 18. Using
firefox connecting to a RHEV-M instance I could launch consoles in
spice-xpi and login so basic support works!
Resolves: rhbz#613529
No new symbols are added, but there is an addition to QXLInterface:
void (*set_client_capabilities)(QXLInstance *qin,
uint8_t client_present,
uint8_t caps[58]);
When a new client connects, there may be commands in the ring that it
can't understand, so we need to process these before forwarding new
commands to the client. By doing this after changing the capability
bits we ensure that the new client will never see a command that it
doesn't understand (under the assumption that the guest will read and
obey the capability bits).
Acked-by: Alon Levy <alonl@redhat.com>
A new interface
set_client_capabilities (QXLInstance *qin,
uint8_t client_present,
uint8_t caps[58]);
is added to QXLInstance, and spice server is changed to call it
whenever a client connects or disconnects. The QXL device in response
is expected to update the client capability bits in the ROM of the
device and raise the QXL_INTERRUPT_CLIENT interrupt.
There is a potential race condition in the case where a client
disconnects and a new client with fewer capabilities connects. There
may be commands in the ring that the new client can't handle. This
case is handled by first changing the capability bits, then processing
all commands in the ring, and then start forwarding commands to the
new client. As long as the guest obeys the capability bits, the new
client will never see anything it doesn't understand.
Just checks stride vs width times bpp.
This fixes a potential abort on guest generated bad images in
glz_encoder.
Other files touched to move some consts to red_common, they are
static so no problem to be defined in both red_worker.c and
red_parse_qxl.c .
replace add_ref with add for stack allocated SpiceMigrateDataDisplay.
This fixes wrong MIGRATE_DATA message in display channel (symptom is
glz_encoder_max being way too big, and malloc failure at target) seen on
F18 with gcc-4.7.1-5.fc18.x86_64 and glibc-2.16-8.fc18.x86_64 (didn't
appear on RHEL 6).
Storing the motion count in uint16_t and not in uint32_t since
the exact count is not important, just its division in
SPICE_INPUT_MOTION_ACK_BUNCH (see the next 2 patches).
red_channel_client_set_message_serial is called for setting
the serial of the display channel messages after migration (on the
destination side). The serial is retrieved from the migration data.
The playback and record channel send SPICE_MSG_MIGRATE to the client.
Both playback and record channel does not have a state to restore:
while in the legacy migration implementation the record channel
used to restore the mode and start time, it looks unnecessary since
the client receives from the src MSG_RECORD_STOP before the migration
completion notification (when the vm is stopped). Afterwards, when the vm
starts on the dest side, the client receives MSG_RECORD_START.
Due to the fix in the previous patch, snd_disconnect_channel can be
called both when there is write/read error in the channel, or from
red_client_destroy (which calls client_cbs.disconnect).
Multiple calls to snd_disconnect_channel resulted in calling
channel->cleanup(channel) more than once (double release).
snd channel wasn't added to be part of the client's channels list.
As a result, when the client was destroyed, or migrated, snd channel
client wasn't destroy, or its migration callback wasn't called.
However, due to adding dummy channels to the client, we need special
handling for calls to disconnecting dummy channel clients.
TODO: we need to refactor snd_worker to use red_channel
