Alon,
I am reading the source code of the vdservice for Windows guest OS.
"vdservice" if fact is a proxy software between Windows application and VirIO
serial driver.
I was suppressed to find that " vdservice" open two Windows kernel
driver. In Windows, I only find one VirtIO PCI driver. Why " vdservice" can
open two kernel drivers?
Do I miss something or something wrong with the implementation? Can you
tell me why?
You can find the following device logical names from pci_vdi_port.cpp
and virtio_vdi_port.cpp.
#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
#define VIOSERIAL_PORT_PATH L"\\\\.\\Global\\com.redhat.spice.0"
I can imagine that device "\\\\.\\Global\\com.redhat.spice.0" is
created from Qemu command line. But where is the device "\\\\.\\VDIPort"
created from?
Why there are two interfaces are exposed to Windows guest OS?
-----Original Message-----
From: Alon Levy [mailto:al...@redhat.com]
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-devel@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS
On Mon, Mar 12, 2012 at 05:51:32PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Alon,
>
> Here is a little bit confusion to me and you might be able to clear my
> puzzle.
>
> If launching a VM by adding the following options can create a separate
> VirIO for virtual printer driver, how the Qemu maps this logical channel to
> printing channel?
> In other words, Windows guest OS writes the data to
> "com.redhat.spice.printer.0" channel through the VirIO API, why the captured
> printing raw data can be seen in printing channel in spice server?
>
> -device virtio-serial,multifunction=on -chardev
> spicevmc,name= printagent,id=printagent -device
> virtserialport,chardev=
> printagent,name= com.redhat.spice.printer.0
>
>
spicevmc chardev would be created once for every -chardev spicevmc command
line, and it will be registered via spice_server_add_interface, see
spice-qemu-char.c for details. The actual implementation for the printagent
subtype would like in spiceserver, but it would open a channel, see:
spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon
>
>
> -----Original Message-----
> From: Alon Levy [mailto:al...@redhat.com]
> Sent: Monday, March 12, 2012 3:17 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: spice-devel@lists.freedesktop.org
> Subject: Re: [Spice-devel] Access local network printer from guest OS
>
> On Mon, Mar 12, 2012 at 10:16:37AM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Alon,
> >
> > Thank you for your prompt response. Please see my comments below inside the
> > pair tag "Charles>>>> <<<Charles"
> >
> >
> > -----Original Message-----
> > From: Alon Levy [mailto:al...@redhat.com]
> > Sent: Saturday, March 10, 2012 6:35 PM
> > To: Charles.Tsai-蔡清海-研究發展部
> > Cc: spice-devel@lists.freedesktop.org
> > Subject: Re: [Spice-devel] Access local network printer from guest
> > OS
> >
> > On Sat, Mar 10, 2012 at 10:58:27AM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > Alon,
> > >
> > > I am implementing the code for the printing redirection for spice
> > > client. In the windows client, I know how to do it. Basically, I just
> > > follow the footprint of the playback channel. However, I still have a
> > > question regarding how my virtual printer driver delivers the printing
> > > raw data to SPICE server.
> > >
> >
> > Why are you copying the playback channel and not one of the red_channel
> > converted channels, like inputs? playback is actually special, it has a
> > bitset of possible pending messages, same for the record channel, while all
> > other channels use a pipe (they can have multiple same type pending
> > messages).
> >
> > > In your previous mail you said,
> > >
> > > > The first device is the virtio-serial bus (pci device), the
> > > chardev is
> > > > that spicevmc chardev, id is whatever you like, name is taken
> > > from a
> > > > list of possible names, see below. The third is the port
> > > device (needs
> > > > to be created after the chardev, the parameters are processed
> > > by order
> > > > given in the command line from left to right), the name is
> > > the guest
> > > > visible device created, I don't rememer exactly the device
> > > name in
> > > > windows but something like \\.\vportfoo-com.redhat.spice.0
> > >
> > >
> > > Do you mean that we need to create another virtual PCI port device in
> > > the guest and the virtual printer driver simply just send the printing
> > > raw data to that virtual PCI port device? If my understanding is
> > > correct, we need to use another vendor ID and product ID in order to
> > > create a new virtual PCI port device for virtual printer driver. Am I
> > > correct?
> > >
> >
> > You don't need a new PCI device, the virtio-serial-bus PCI device supports
> > a number (don't know the limit) of different logical ports, i.e. different
> > streams between the guest and the host.
> >
> >
> > Charles>>>>
> > This is what I thought after reading your suggestion. In Windows guest OS,
> > the application refers to a logical PCI channel by a device name, for
> > instance "\\\\.\\Global\\com.redhat.spice.0". But logical device name
> > "\\\\.\\Global\\com.redhat.spice.0" is used by "spice agent" already. If
> > we do not create another PCI logical channel for virtual printing device,
> > how the virtual printer driver can talk to that device.
> >
>
> So we are talking about the same thing, I assumed you meant a different PCI
> device but from the above paragraph I understand you are talking about a
> virtserialport, not a different PCI device. Calling it a "PCI logical
> channel" is fine.
>
> > Can we do something as follows to create a logical device for
> > printer device
> >
> > -device virtio-serial,multifunction=on -chardev
> > spicevmc,name=vdagent,id=printagent -device virtserialport,chardev=
> > printagent,name=com.redhat.spice.1
>
> Yes, but better to use a more descriptive name I guess, the
> com.redhat.spice.0 idea was not good enough. Maybe keep the
> "com.redhat.spice" part but add a printer namespace:
> "com.redhat.spice.printer.0"
>
> Would you have one per printer?
>
> >
> > In Windows guest OS, printer driver simply just opens the logical device
> > named "com.redhat.spice.1". After the logical virtio device is opened,
> > printer driver can write the printing raw data to the PCI logical channel
> > by calling the VirtIO API.
> >
> > <<<Charles
> >
> >
> >
> > >
> > > Lastly, I read the SPICE server code for USB redirect. I only found a
> > > generic code to handle the messages for char device. For the virtual
> > > printer driver, it seems to not be able to apply to this case,
> > > because
> > >
> > >
> > > 1. the virtual printer driver needs to know which device to talk in
> > > order to send the printing raw data to SPICE server.
> >
> > USB has the same problem - there can be a number of USB devices on the
> > client, and all wanting to be exposed to the guest. What USB redirection
> > does is create a spicevmc channel plus use a spicevmc chardev for each
> > device. You could do the same thing.
> >
> > Charles>>>>
> > I see your points. How the virtual printing device opens the VirtIo device
> > for the printing channel is the questions I tried to know.
> > Please see my above question.
> > <<<Charles
> >
> >
> >
> > > 2. SPICE server needs to pack the printing raw data in a right format
> > > and send it to the spice client.
> > >
> >
> > I'm not sure what the problem here is - if you use spicevmc you would not
> > specify the format of the message passed in this channel via the
> > spice.proto file, but instead pass it opaquely for the server, and only
> > parse it in the guest/host and in the client. Actually I don't think you
> > said what your plans are for the guest/host - how are you going to pass the
> > data from the windows vm to the spice server? are you introducing a new
> > component in the guest? a driver? a user space component that isn't a
> > driver? will you be augmenting spice-vdagent or using something of your
> > own? do you plan to release it under an open source license?
> >
> > Charles>>>>
> > So far, I am still testing the printer driver on a physical machine to
> > prove my concept. Basically, it will be a virtual printer driver. This
> > driver will capture the printing raw data and forward the captured raw data
> > from VM to the spice client. Upon receiving the printing raw data, the
> > spice client will print it from the local printer device.
>
> I see. This is totally one directional? And how would the spice client cope
> with it's own different local printer drivers? and how would you expose
> multiple available printers in the client to the guest?
>
> > <<<Charles
> >
> >
> >
> > >
> > > Please let me know if I miss some points to the understanding of
> > > the SPICE protocol regarding the implementation of the printing
> > > redirection. Thanks
> > >
> > > Note that "printing redirection" is one-way communication that is
> > > initiated from Windows guest OS(VM) to spice client.
> > >
> > >
> > > -----Original Message-----
> > > From: Alon Levy [mailto:al...@redhat.com]
> > > Sent: Monday, January 02, 2012 7:49 PM
> > > To: Charles.Tsai-蔡清海-工程部
> > > Cc: spice-devel@lists.freedesktop.org; Alex Huang-黃必賢-工程部
> > > Subject: Re: [Spice-devel] Access local network printer from guest
> > > OS
> > >
> > > On Mon, Jan 02, 2012 at 07:08:23PM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > Alon,
> > > >
> > > > I have another question regarding the USB redirect for Windows client.
> > > > In current spice release, the USB redirect only support for Linux
> > > > client.
> > >
> > > Right, but this is a temporary situation, it will be supported in windows
> > > clients.
> > >
> > > > If we send the printing data through the "spicevmc channel" to the
> > > > Windows client(not Linux), what is the corresponding channel(file and
> > > > function) in client to receive the printing data?
> > >
> > > That would be the SPICE_CHANNEL_PRINTER you would define. Look at the
> > > usbredir channel as an example, or the smartcard channel. (but usbredir
> > > is better).
> > >
> > > > Is there a files in LINUX client for us to do the design reference?
> > >
> > > look at the usbredir implementation in the spice-gtk client.
> > > channel-usbredir.c.
> > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Alon Levy [mailto:al...@redhat.com]
> > > > Sent: Monday, January 02, 2012 6:19 PM
> > > > To: Charles.Tsai-蔡清海-工程部
> > > > Cc: spice-devel@lists.freedesktop.org
> > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > guest OS
> > > >
> > > > On Mon, Jan 02, 2012 at 10:06:34AM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > Alon,
> > > > >
> > > > > Let me recap what you suggest in case that I missed your point.
> > > >
> > > > sure.
> > > >
> > > > >
> > > > > 1. Capturing the printing data from the virtual printer driver.
> > > > > 2. send the captured data to the " cifs/ipp server" for printing data.
> > > > > 3. send the printing data to VDI port driver(virtioserial driver).
> > > > > 4. Spicevmc(in spice server)receives the printing data from VDI port
> > > > > driver.
> > > > >
> > > > >
> > > > > In the above scenario, there is nothing to be changed in spice
> > > > > server. Here is my questions regarding this design.
> > > > >
> > > > > 1. Why cannot virtual printer driver send the captured data to the
> > > > > VDI port driver directly? The spice agent talks to the VDI port
> > > > > driver directly, doesn't it?
> > > > >
> > > > > The virtual printer driver I want to implement is the printer port
> > > > > monitor driver. It captures the printing data between user-mode print
> > > > > spooler and the kernel-mode port drivers that access I/O port
> > > > > hardware.
> > > >
> > > > I didn't understand your suggestion to be so specific to windows guests.
> > > > If you intend to write a windows guest printer port monitor driver (I
> > > > assume it's a windows guest thing, right?) then of course you don't
> > > > need an additional guest side anything, and you are correct to point
> > > > this out.
> > > >
> > > > >
> > > > > 2. Which files or functions in virtioserial driver talks to "spicevmc
> > > > > channel"?
> > > > >
> > > > > This question is related to question 1. If I know the way how the
> > > > > virtioserial and the spicevmc talk, I can modify my design too.
> > > > >
> > > >
> > > > You create a virtioserial port, you create a chardev, and you tell qemu
> > > > to connect the port to the chardev, all from the command line:
> > > > -device virtio-serial,multifunction=on -chardev
> > > > spicevmc,name=vdagent,id=vdagent -device
> > > > virtserialport,chardev=vdagent,name=com.redhat.spice.0
> > > >
> > > > The first device is the virtio-serial bus (pci device), the
> > > > chardev is that spicevmc chardev, id is whatever you like, name
> > > > is taken from a list of possible names, see below. The third is
> > > > the port device (needs to be created after the chardev, the
> > > > parameters are processed by order given in the command line from
> > > > left to right), the name is the guest visible device created, I
> > > > don't rememer exactly the device name in windows but something
> > > > like
> > > > \\.\vportfoo-com.redhat.spice.0
> > > >
> > > >
> > > > Adding a fourth SUBTYPE (there are currently three - VDAGENT,
> > > > SMARTCARD,
> > > > USBREDIR) is something like this (and yes, it looks like it might be
> > > > nice to make it a switch):
> > > >
> > > > diff --git a/server/reds.c b/server/reds.c index
> > > > acd8495..102c254
> > > > 100644
> > > > --- a/server/reds.c
> > > > +++ b/server/reds.c
> > > > @@ -3261,6 +3261,7 @@ SPICE_GNUC_VISIBLE void
> > > > spice_server_char_device_wakeup(SpiceCharDeviceInstance*
> > > > #define SUBTYPE_VDAGENT "vdagent"
> > > > #define SUBTYPE_SMARTCARD "smartcard"
> > > > #define SUBTYPE_USBREDIR "usbredir"
> > > > +#define SUBTYPE_PRINTER "printer"
> > > >
> > > > const char *spice_server_char_device_recognized_subtypes_list[] = {
> > > > SUBTYPE_VDAGENT,
> > > > @@ -3268,6 +3269,7 @@ const char
> > > > *spice_server_char_device_recognized_subtypes_list[] = {
> > > > SUBTYPE_SMARTCARD,
> > > > #endif
> > > > SUBTYPE_USBREDIR,
> > > > + SUBTYPE_PRINTER,
> > > > NULL,
> > > > };
> > > >
> > > > @@ -3300,6 +3302,8 @@ static int
> > > > spice_server_char_device_add_interface(SpiceServer *s, #endif
> > > > else if (strcmp(char_device->subtype, SUBTYPE_USBREDIR) == 0) {
> > > > spicevmc_device_connect(char_device,
> > > > SPICE_CHANNEL_USBREDIR);
> > > > + } else if (strcmp(char_device->subtype, SUBTYPE_PRINTER) == 0) {
> > > > + spicevmc_device_connect(char_device,
> > > > + SPICE_CHANNEL_PRINTER);
> > > > }
> > > > return 0;
> > > > }
> > > >
> > > >
> > > > Defining SPICE_CHANNEL_PRINTER is done via the codegen stuff, you just
> > > > update spice.proto and run something to produce an updated enums.h.
> > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Alon Levy [mailto:al...@redhat.com]
> > > > > Sent: Sunday, January 01, 2012 10:19 PM
> > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > Cc: spice-devel@lists.freedesktop.org
> > > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > > guest OS
> > > > >
> > > > > On Sun, Jan 01, 2012 at 09:08:52PM +0800, Charles.Tsai-蔡清海-工程部 wrote:
> > > > > > Hi Alon,
> > > > > >
> > > > > > Your information is extremely valuable for us. I think adding one
> > > > > > additional channel is a good solution.
> > > > > > Because I haven't programmed QEMU before, I have a question
> > > > > > regarding creating a virtual printer device.
> > > > > > In spice agent, the way that the SPICE agent talks to the SPICE
> > > > > > server is through a virtual serial port device.
> > > > > > For the virtual printer device, do I need to create a
> > > > > > similar virtual I/O for the printer? To send the printing data to
> > > > > > the SPICE server from guest OS, the virtual printer device driver
> > > > > > will write the printing data to the virtual I/O like a real
> > > > > > hardware device. In QEMU, can I find any information about this?
> > > > > > Thanks.
> > > > > >
> > > > >
> > > > > I am not sure how good the idea of creating a virtual printer is. I
> > > > > see two options, each not optimal:
> > > > > 1. expose the real printer.
> > > > > + all features of real printer are avaliable
> > > > > - guest has to have real printer drivers (so each new client or new
> > > > > printer on client side requires guest driver installation). This
> > > > > is
> > > > > not neccessarily hard/bad.
> > > > > 2. expose a fixed printer (this is what you are proposing)
> > > > > - subset / fixed set of features.
> > > > > + no new driver to install, only one time driver install.
> > > > >
> > > > > We have previously intended the tunnel channel to provide the printer
> > > > > remoting. But you don't have to expose a whole network tunnel, you
> > > > > could implement a cifs/ipp server with printing services. That could
> > > > > be implemented as a guest daemon talking over a virtioserial port and
> > > > > a spicevmc channel to the client, which means you won't have to
> > > > > change qemu at all, but you would have to add a guest feature (so
> > > > > needs to be implemented and installed for every guest os you want to
> > > > > support). I suppose such a service could also be implemented at the
> > > > > qemu level, and still use a spicevmc channel so no spice server
> > > > > changes either way. I'm not sure what kind of virtual printer you
> > > > > have in mind.
> > > > >
> > > > > I haven't actually answer you so far:
> > > > > - no, you don't need to create a new virtual I/O channel,
> > > > > virtioserial
> > > > > is just the virtual I/O you need.
> > > > >
> > > > > HTH
> > > > > Alon
> > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alon Levy [mailto:al...@redhat.com]
> > > > > > Sent: Sunday, January 01, 2012 7:45 PM
> > > > > > To: Charles.Tsai-蔡清海-工程部
> > > > > > Cc: spice-devel@lists.freedesktop.org
> > > > > > Subject: Re: [Spice-devel] Access local network printer from
> > > > > > guest OS
> > > > > >
> > > > > > On Sun, Jan 01, 2012 at 10:41:14AM +0800, Charles.Tsai-蔡清海-工程部
> > > > > > wrote:
> > > > > > > All,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > We planned to implement the software to access the local
> > > > > > > network printer
> > > > > > > from the guest OS over the SPICE. I did see someone post a
> > > > > > > message before
> > > > > > > talking about the implementation of the network redirect
> > > > > > > before. But the
> > > > > > > solution seems to be too complicated for us. Here is my design
> > > > > > > ideas to
> > > > > > > implement the access of the local network printer from the
> > > > > > > guest OS.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1. Implemented a virtual printer driver in the guest OS.
> > > > > > >
> > > > > > > 2. Intercept the printing data from the virtual printer
> > > > > > > driver and
> > > > > > > forward it to the spice agent.
> > > > > > >
> > > > > > > 3. Deliver the printing data from the spice agent
> > > > > > > through the
> > > > > > > .$B!H.(Bmain channel.$B!I.(B
> > > > > > >
> > > > > > > 4. Spice client receives the printing data and set it to
> > > > > > > the local
> > > > > > > network printer.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Based on my design ideas, I have a couple of questions.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 1. Currently, main channel is used by spice agent for
> > > > > > > enchaining the
> > > > > > > user experience. Can I expand it to delivered printing data?
> > > > > > > Any pros and
> > > > > > > cons?
> > > > > > >
> > > > > > > 2. How easily it is to expand one additional channel
> > > > > > > for priming
> > > > > > > data if .$B!H.(Bmain channel.$B!I.(B is not a good approach to
> > > > > > > send
> > > > > > > printing data?
> > > > > > >
> > > > > >
> > > > > > I would suggest going with adding an additional channel rather then
> > > > > > adding messages to main channel. imo the existance of agent data in
> > > > > > the main channel is not a good thing and shouldn't be taken as an
> > > > > > example of how to do things.
> > > > > >
> > > > > > To add a new channel you basically need to:
> > > > > > 1. add the channel to spice.proto (in spice repository) There are
> > > > > > two options here - you can use an opaque channel, and by opaque I
> > > > > > mean that the messages it contains are Data messages, no
> > > > > > additional information is in them and you have to do parsing
> > > > > > "yourself", without the code generation done from spice.proto. If
> > > > > > you want to use the code generator then you can take any other
> > > > > > channel message as an example. You will then need to update the
> > > > > > spice-protocol headers as well, common/messages.h 2. implement
> > > > > > server side - the steps are:
> > > > > > create the new channel. Follow the inputs channel as a good
> > > > > > example.
> > > > > > (server/inputs_channel.c:inputs_init)
> > > > > > advertise the new channel. This is taken care of by calling
> > > > > > reds_register_channel.
> > > > > > you will need to do work based on some call backs from either
> > > > > > direction:
> > > > > > qemu initiated (guest did something to the virtual printer
> > > > > > device)
> > > > > > client initiated (callback set during channel creation, in inputs
> > > > > > it is inputs_channel_handle_parsed) 3. client side
> > > > > > implementation:
> > > > > > you should be working on the spice-gtk client, it is in it's own
> > > > > > repository. You will have to make sure the changes (if any) you do
> > > > > > to the common subdirectory are copied over since it has it's own
> > > > > > copy. Haven't worked on spice-gtk but it looks like again starting
> > > > > > from some existing channel like gtk/channel-inputs could be a good
> > > > > > idea.
> > > > > >
> > > > > > HTH,
> > > > > > Alon
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > > _______________________________________________
> > > > > > > Spice-devel mailing list
> > > > > > > Spice-devel@lists.freedesktop.org
> > > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > > > > >
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
