qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] spice: add chardev (v3)
Date: Thu, 06 Jan 2011 13:05:33 +0100	[thread overview]
Message-ID: <4D25B00D.1090500@redhat.com> (raw)
In-Reply-To: <4D0B7B4B.4040500@codemonkey.ws>

On 12/17/10 16:01, Anthony Liguori wrote:
> On 12/17/2010 07:39 AM, Alon Levy wrote:
>> Adding a chardev backend for spice, for usage by spice vdagent in
>> conjunction with a properly named virtio-serial device.
>>
>> Example usage:
>> qemu -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent
>> -devic

This example is incomplete btw ...

> What doe this channel do?

It is a communication path between spice client and guest.

There used to be just one, for vdagent (spice guest agent) which sends 
mouse events for example.  There will be more in the future, and using 
chardevs allows us to handle that.

> I really don't feel comfortable with this. This is not connecting QEMU
> to an existing interface that happens to fit our model.
>
> This is clearly a "library" that provides thin wrappers around internal
> QEMU interfaces to implement code that belongs in QEMU outside of QEMU.

No.  This is about tunneling server/client connections through spice, so 
we can reuse the authentication and encryption provided by spice.

Assume you have your VM running on machine A and you are sitting in 
front of machine B.  You want use the smartcard attached to host B in 
your virtual machine.

Without spice you'll use this on machine A:
    qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait \
       -usb -device usb-ccid -device ccid-card-passthru,chardev=ccid

and run "vscclient <machine A> 2001" on machine B.

With spice you'll use this on machine A:
   qemu -chardev spicevmc,id=ccid,name=smartcard \
       -usb -device usb-ccid -device ccid-card-passthru,chardev=ccid

and the spice client on machine B will forward the requests to vscclient 
(well, I think it is actually linked to libcaccard, which is effectively 
the same as vscclient just forwards the requests from the network to 
libcaccard too).

There is no hidden magic.

cheers,
   Gerd

  parent reply	other threads:[~2011-01-06 12:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17 13:39 [Qemu-devel] [PATCH] spice: add chardev (v3) Alon Levy
2010-12-17 15:01 ` Anthony Liguori
2010-12-17 19:37   ` Alon Levy
2011-01-06 12:05   ` Gerd Hoffmann [this message]
2011-01-06 12:23     ` Alon Levy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D25B00D.1090500@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alevy@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).