On 03/11/2012 10:25 AM, Alon Levy wrote:
On Sun, Mar 11, 2012 at 09:18:17AM -0500, Anthony Liguori wrote:
On 03/11/2012 08:16 AM, Yonit Halperin wrote:
Hi,
We would like to implement seamless migration for Spice, i.e., keeping the
currently opened spice client session valid after migration
cycle for
1.2, then that's a pretty reasonable target IMHO.
Regards,
Anthony Liguori
The straightforward solution would be to process the main loop on the
destination side during migration.
(2) In order to restore the source-client spice session in the destination, we
need to pass dat
nts are ready to
migrate ends up being nicer. It means that we never end up with a blocked QMP
session and clients are more likely to properly deal with the fact that an event
may take arbitrarily long to happen.
Clients can also implement their own cancel logic by choosing to sto
of locking too. I
think the best way to resolve this is to fix libspice and not try to
work around the problem in QEMU.
Regards,
Anthony Liguori
Paolo
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org
27;d rather that we have very clear rules about what's thread safe and
not thread safe. If you want to audit the QObject subsystem, declare it
thread safe, and document it as such, that would be okay. But it needs
to be systematic, not ad-hoc.
Regards,
Anthony Liguori
Can you just us
I like the idea of still calling QEMU code
without holding the mutex (even the QObject code).
Can you just use a bottom half to defer this work to the I/O thread?
Bottom half scheduling has to be signal safe which means it will also be
thread safe.
Regards,
Anthony
ing *any* QEMU code without holding the global
mutex. That includes all of the QObject interactions.
Regards,
Anthony Liguori
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
g else and then handle the return
logic.
Having QEMU as an intermediary is important to preserve our current
security model. We shouldn't be passing unsanitized guest input to an
external process.
Regards,
Anthony Liguori
cheers,
Gerd
___
On 03/01/2011 09:25 AM, Dor Laor wrote:
On 03/01/2011 02:40 PM, Anthony Liguori wrote:
On Mar 1, 2011 7:07 AM, "Dor Laor" mailto:dl...@redhat.com>> wrote:
>
> On 02/28/2011 07:44 PM, Anthony Liguori wrote:
>>
>>
>> On Feb 28, 2011 10:44 AM, "
On 01/27/2011 08:53 AM, Gerd Hoffmann wrote:
On 01/27/11 15:27, Anthony Liguori wrote:
On 01/27/2011 07:11 AM, Gerd Hoffmann wrote:
Hi,
Next revision the pvmouse protocol. It is quite different now, I've
decided to move to a model with one message per updated value, simliar
to the linux
I like the new interface.
Regards,
Anthony Liguori
thanks,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
pture,
PV mouse in absolute mode, PV mouse in multitouch mode, etc.
VirtualBox has an interface like this FWIW (although not multitouch aware).
Regards,
Anthony Liguori
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedeskto
On 01/17/2011 02:19 AM, Gerd Hoffmann wrote:
On 01/14/11 21:48, Anthony Liguori wrote:
On 01/14/2011 10:35 AM, Gerd Hoffmann wrote:
Hi,
Now v3 featuring multitouch ;)
cheers,
Gerd
I really think multitouch needs to be a feature such that the guest can
nack it and the host can adjust
a feature.
There are a lot of non-multitouch aware guests out there and I don't
think we want the driver to be the one deciding how to map a multitouch
device to something that doesn't support mulitouch.
Regards,
Anthony Liguori
___
Spic
x27;s just do
what it does instead of inventing something that none of us can validate
actually works.
Or better yet, delay implementing it until someone actually knows how to
support it.
Regards,
Anthony Liguori
This would even be useful for single-point tablets which usually also h
qemu_pvtablet_position position;
qemu_pvtablet_button button;
};
typedef struct qemu_pvtablet_message {
qemu_pvtablet_header hdr;
qemu_pvtablet_payload data;
} qemu_pvtablet_message;
Regards,
Anthony Liguori
#endif /* __QEMU_PVTABLET__ */
_
wiki/Multi-Pointer_X
Yeah, that's exactly what I had in mind and why I suggested an offscreen
coordinate.
Regards,
Anthony Liguori
Regards,
Daniel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/m
beginning too.
Features negotiation takes care of this.
Regards,
Anthony Liguori
Alex
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
On 01/13/2011 11:08 AM, Gerd Hoffmann wrote:
On 01/13/11 16:55, Anthony Liguori wrote:
On 01/13/2011 05:51 AM, Gerd Hoffmann wrote:
On 01/13/11 12:01, Stefan Hajnoczi wrote:
Can you elaborate how the spice display channel comes into play? On a
physical machine you just have input devices
On 01/13/2011 11:09 AM, Paolo Bonzini wrote:
On 01/13/2011 05:39 PM, Anthony Liguori wrote:
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host->guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x a
t_position {
struct qemu_pvtablet_hdr hdr;
uint32_t x;
uint32_t y;
};
union qemu_pvtablet_message {
struct qemu_pvtablet_hdr hdr;
struct qemu_pvtablet_position position;
...
};
Regards,
Anthony Liguori
___
Spice-devel mailing
On 01/13/2011 10:14 AM, Avi Kivity wrote:
On 01/13/2011 05:52 PM, Anthony Liguori wrote:
/* host->guest, sent before any other events */
typedef struct qemu_pvtablet_init {
uint32_t res_x; /* x axis resolution */
uint32_t res_y; /* y axis resolution */
uint32_t featu
l axis
to cover pressure sensitive touchpads. Not worth designing now but a
feature negotiation gives us the option later.
Regards,
Anthony Liguori
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freed
QEMU_PVTABLE_MSG_ACK, /* qemu_pvtable_ack */
Regards,
Anthony Liguori
};
typedef struct qemu_pvtablet_message {
uint32_t size;/* whole message size */
uint32_t type;/* qemu_pvtablet_type */
uint64_t tv_secs;
uint64_t tv_usecs;
union {
pice/spice/tree/spice.proto
Of course there are many implementations of this outside of spice, like protocol
buffers). I also don't think a one-off is necessarily a bad thing.
Yeah, it might be worthwhile to look at protocol buffers.
Regards,
Anthony Liguori
Note while on the subjec
On 01/12/2011 12:59 PM, Hans de Goede wrote:
Hi,
On 01/12/2011 06:40 PM, Anthony Liguori wrote:
On 01/12/2011 10:12 AM, Gerd Hoffmann wrote:
Hi folks,
Looks like the spicevmc patch kicked the guest qagent discussion, so
lets start with this, although it isn't related much to the
discussion about agent design first to make sure that we're on the same
page.
For instance, Spice makes use of a 1-off protocol whereas something like
virt-agent uses an established RPC protocol (XML-RPC). I'm not tied to
using any particular protocol, but
U out the picture which creates a clean separation layer.
There are emulated devices in QEMU which we create and control and then
there are passthrough devices that QEMU doesn't have any role in creating.
Regards,
Anthony Liguori
Rgrds,
Attila
2010/11/29 Gerd Hoffmann mailto:kra...@
On 11/10/2010 03:06 AM, Hans de Goede wrote:
This allows us to recreate the sysfspath used during scanning later
(which will be used in a later patch in this series).
Applied all three. Thanks.
Regards,
Anthony Liguori
---
usb-linux.c | 26 +++---
1 files
29 matches
Mail list logo
