Re: 1cec1c5118b65124de6bc6f984f376ff4e297bfb ("reds: Make VDIPortState a GObject") changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, Jun 02, 2016 at 10:11:33AM -0400, Frediano Ziglio wrote:
> >
> > Hi,
> >   I think this patch is one of the most puzzling commit and caused
> > some regression (2 patches applied and one going).
> > The problem was not actually the move to GObject but that the
> > implementation change completely the lifetime of the underlying
> > RedCharDevice.
> > Before the patch the RedCharDevice was created when Qemu created the
> > device and possibly destroyed when device is destroyed but also on
> > some errors from the main channel.
> > I tried to understand what the other RedCharDevice do. SpiceVmc and
> > SmartCard basically create the device when Qemu create it and destroy
> > when Qemu destroy them (currently never). When the device is created
> > a channel is created. Here there are some differences. The VDI
> > CharDevice is already present, no matter if a Qemu device is present
> > or not. Also the MainChannel (the channel corresponding to the VDI
> > CharDevice) is always present and not created when the VDI CharDevice
> > is created. These 2 differences were however already present before
> > this patch.
> > One of the difference is that before an error could lead to
> > destroying the CharDevice basically causing all future MainChannels
> > to have a not working agent (as the agent requires a working CharDevice).
> >
> > At the end I consider this as a good patch and in line with what other
> > CharDevices are working (the CharDevice is destroyed only by Qemu) however
> > there are cases were before CharDevice was not present and now is it.
> > Particularly what happens when the agent is stopped in the guest?
> > The guest agent is informed so won't send data?
> > Is it stopped when sending large data (as instance large file)? Or
> > will send lot of data that will be ignored by the server?
> > In case of errors agent_attached is set to FALSE but who will set again
> > this field to TRUE? Apparently this is set to TRUE only in
> > attach_to_red_agent
> > called during spice_server_add_interface so this will be set back to TRUE
> > only during migration. Looks like this is a bug, guest should be able
> > to launch again the agent and variable should be set back to TRUE.
>
> This morning we had some issues with agents and we did some tests.
> Turns out that Qemu create the CharDevice when guest attach to the device,
> not when Qemu starts.
> This change a lot the life and state of the device.
> This causes some sync problem between server and client.
> I'm actually considering a rollback.

If I'm following the discussion correctly (from IRC) the main regression
is the recently problems with server <-> client when agent is
restarted/killed under ongoing operation like file-transfer.

I agree that this is a good moment double check the code as it's been a
few bugs already but I'm not 100% sure that all of them were related to
this patch or if it was even possible before (i.e not a regression).

I'll try to take a look on this today and provide a better feedback.
  toso
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]