[Spice-devel] Access local network printer from guest OS

[Charles.Tsai-蔡清海-工程部]

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(Jmain channel$B!I(J

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(Jmain channel$B!I(J is not a good approach to send printing data?

[Alon Levy]

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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-工程部]

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.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

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
http://lists.freedesktop.org/mailma

[Alon Levy]

Post by Charles.Tsai-蔡清海-工程部
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

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-工程部]

Alon,

Let me recap what you suggest in case that I missed your point.

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.

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.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedeskto

[Alon Levy]

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-工程部]

Alon,

Thank you for your further explanation. It is very clear that I understand how the VirIO work now.
Yes, the virtual printer driver I want to support at this moment is for Windows guest OS only.
The support of the Linux guest OS will be considered latter on.




-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/

[Charles.Tsai-蔡清海-工程部]

Alon,

I have another question regarding the USB redirect for Windows client. In current spice release, the USB redirect only support for Linux client.
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?
Is there a files in LINUX client for us to do the design reference?



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Alon Levy]

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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).

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Alon,

I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the pe

[Stefan Hajnoczi]

Post by Charles.Tsai-蔡清海-研究發展部
I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the person.

I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.

Please post your QEMU command-line so we can see how the guest is configured.

You mentioned that you debugged the driver and hardware resources
weren't allocated. Do you have a virtio PCI device inside the guest
for this virtio-serial device? Were you able to tell which part of
driver initialization failed (finding the PCI device, mapping its
resources (BARs), etc)?

Stefan

[Vadim Rozenfeld]

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the person.

I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
Please post your QEMU command-line so we can see how the guest is configured.
You mentioned that you debugged the driver and hardware resources
weren't allocated. Do you have a virtio PCI device inside the guest
for this virtio-serial device? Were you able to tell which part of
driver initialization failed (finding the PCI device, mapping its
resources (BARs), etc)?
Stefan

Could you post "pci info" output?

thanks,
Vadim.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

Thank you for your prompt reply. Here are the information for our test case.


1) we use the following command line to launch the guest OS


/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win_xp -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
-drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=17,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0



2). In Guest Windows XP OS


When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.


VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.

I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", __FUNCTION__,nListSize);


So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.




-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, January 15, 2012 7:42 PM
To: Stefan Hajnoczi
Cc: Charles.Tsai-蔡清海-研究發展部; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; qemu-devel
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the person.

I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
Please post your QEMU command-line so we can see how the guest is configured.
You mentioned that you debugged the driver and hardware resources
weren't allocated. Do you have a virtio PCI device inside the guest
for this virtio-serial device? Were you able to tell which part of
driver initialization failed (finding the PCI device, mapping its
resources (BARs), etc)?
Stefan

Could you post "pci info" outp

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win_xp -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
-drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=17,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
You're right.
If WdfCmResourceListGetCount returns zero,
it must be a problem with resources list.
Output of "info pci" and "info qtree" commands
could be helpful in analyzing this problem.

Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Sunday, January 15, 2012 7:42 PM
To: Stefan Hajnoczi
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the person.

I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
Please post your QEMU command-line so we can see how the guest is configured.
You mentioned that you debugged the driver and hardware resources
weren't allocated. Do you have a virtio PCI device inside the guest
for this virtio-serial device? Were you able to tell which part of
driver initialization failed (finding the PCI device, mapping its
resources (BARs), etc)?
Stefan

Could you post "pci info" output?
thanks,
Vadim.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

I just ran the Qemu monitor to get the PCI information. The information is listed belowe.
From the listed information, I did not see anything wrong with the BAR0.
-----------


INFO:
Bus 0, device 0, function 0:
Host bridge: PCI device 8086:1237
id ""
Bus 0, device 1, function 0:
ISA bridge: PCI device 8086:7000
id ""
Bus 0, device 1, function 1:
IDE controller: PCI device 8086:7010
BAR4: I/O at 0xc000 [0xc00f].
id ""
Bus 0, device 1, function 2:
USB controller: PCI device 8086:7020
IRQ 10.
BAR4: I/O at 0xc020 [0xc03f].
id ""
Bus 0, device 1, function 3:
Bridge: PCI device 8086:7113
IRQ 9.
id ""
Bus 0, device 2, function 0:
VGA controller: PCI device 1b36:0100
IRQ 5.
BAR0: 32 bit memory at 0xf0000000 [0xf3ffffff].
BAR1: 32 bit memory at 0xf4000000 [0xf7ffffff].
BAR2: 32 bit memory at 0xf8000000 [0xf8001fff].
BAR3: I/O at 0xc040 [0xc05f].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
id ""
Bus 0, device 3, function 0:
Ethernet controller: PCI device 10ec:8139
IRQ 10.
BAR0: I/O at 0xc100 [0xc1ff].
BAR1: 32 bit memory at 0xffffffffffffffff [0x000000fe].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
id "net0"
Bus 0, device 4, function 0:
RAM controller: PCI device 1af4:1002
IRQ 11.
BAR0: I/O at 0xc200 [0xc21f].
id "balloon0"
Bus 0, device 5, function 0:
Class 1920: PCI device 1af4:1003
IRQ 11.
BAR0: I/O at 0xc220 [0xc23f].
BAR1: 32 bit memory at 0xf8040000 [0xf8040fff].
id "virtio-serial0"



QTREE:
bus: main-system-bus
type System
dev: hpet, id ""
gpio-in 1
dev-prop: timers = 3
dev-prop: msi = off
irq 32
mmio 00000000fed00000/0000000000000400
dev: i440FX-pcihost, id ""
irq 0
bus: pci.0
type PCI
dev: virtio-balloon-pci, id "balloon0"
dev-prop: indirect_desc = on
dev-prop: event_idx = on
bus-prop: addr = 04.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = on
bus-prop: command_serr_enable = on
class RAM controller, addr 00:04.0, pci id 1af4:1002 (sub 1af4:0005)
bar 0: i/o at 0xc200 [0xc21f]
dev: rtl8139, id "net0"
dev-prop: mac = 52:54:00:e8:dc:b1
dev-prop: vlan = <null>
dev-prop: netdev = hostnet0
dev-prop: bootindex = -1
bus-prop: addr = 03.0
bus-prop: romfile = "pxe-rtl8139.rom"
bus-prop: rombar = 1
bus-prop: multifunction = on
bus-prop: command_serr_enable = on
class Ethernet controller, addr 00:03.0, pci id 10ec:8139 (sub 1af4:1100)
bar 0: i/o at 0xc100 [0xc1ff]
bar 1: mem at 0xffffffffffffffff [0xfe]
bar 6: mem at 0xffffffffffffffff [0xfffe]
dev: virtio-serial-pci, id "virtio-serial0"
dev-prop: ioeventfd = on
dev-prop: vectors = 32
dev-prop: class = 0x780
dev-prop: indirect_desc = on
dev-prop: event_idx = on
dev-prop: max_ports = 31
bus-prop: addr = 05.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = on
bus-prop: command_serr_enable = on
class Class 0780, addr 00:05.0, pci id 1af4:1003 (sub 1af4:0003)
bar 0: i/o at 0xc220 [0xc23f]
bar 1: mem at 0xf8040000 [0xf8040fff]
bus: virtio-serial0.0
type virtio-serial-bus
dev: virtserialport, id "channel0"
dev-prop: chardev = charchannel0
bus-prop: nr = 1
bus-prop: name = "com.redhat.spice.0"
port 1, guest on, host on, throttle off
dev: PIIX4_PM, id ""
dev-prop: smb_io_base = 45312
bus-prop: addr = 01.3
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Bridge, addr 00:01.3, pci id 8086:7113 (sub 1af4:1100)
bus: i2c
type I2C
dev: smbus-eeprom, id ""
bus-prop: address = 87
dev: smbus-eeprom, id ""
bus-prop: address = 86
dev: smbus-eeprom, id ""
bus-prop: address = 85
dev: smbus-eeprom, id ""
bus-prop: address = 84
dev: smbus-eeprom, id ""
bus-prop: address = 83
dev: smbus-eeprom, id ""
bus-prop: address = 82
dev: smbus-eeprom, id ""
bus-prop: address = 81
dev: smbus-eeprom, id ""
bus-prop: address = 80
dev: piix3-usb-uhci, id ""
dev-prop: masterbus = <null>
dev-prop: firstport = 0
bus-prop: addr = 01.2
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class USB controller, addr 00:01.2, pci id 8086:7020 (sub 1af4:1100)
bar 4: i/o at 0xc020 [0xc03f]
bus: usb.0
type USB
dev: usb-tablet, id "input0"
bus-prop: port = <null>
addr 0.1, port 1, speed 12, name QEMU USB Tablet, attached
dev: piix3-ide, id ""
bus-prop: addr = 01.1
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class IDE controller, addr 00:01.1, pci id 8086:7010 (sub 1af4:1100)
bar 4: i/o at 0xc000 [0xc00f]
bus: ide.1
type IDE
bus: ide.0
type IDE
dev: ide-drive, id "ide0-0-0"
dev-prop: drive = drive-ide0-0-0
dev-prop: logical_block_size = 512
dev-prop: physical_block_size = 512
dev-prop: min_io_size = 0
dev-prop: opt_io_size = 0
dev-prop: bootindex = 1
dev-prop: discard_granularity = 0
dev-prop: ver = "0.15.0"
dev-prop: serial = "QM00001"
bus-prop: unit = 0
dev: qxl-vga, id ""
dev-prop: ram_size = 67108864
dev-prop: vram_size = 67108864
dev-prop: revision = 3
dev-prop: debug = 0
dev-prop: guestdebug = 0
dev-prop: cmdlog = 0
bus-prop: addr = 02.0
bus-prop: romfile = "vgabios-qxl.bin"
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class VGA controller, addr 00:02.0, pci id 1b36:0100 (sub 1af4:1100)
bar 0: mem at 0xf0000000 [0xf3ffffff]
bar 1: mem at 0xf4000000 [0xf7ffffff]
bar 2: mem at 0xf8000000 [0xf8001fff]
bar 3: i/o at 0xc040 [0xc05f]
bar 6: mem at 0xffffffffffffffff [0xfffe]
dev: PIIX3, id ""
bus-prop: addr = 01.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = on
bus-prop: command_serr_enable = on
class ISA bridge, addr 00:01.0, pci id 8086:7000 (sub 1af4:1100)
bus: isa.0
type ISA
dev: isa-serial, id "serial0"
dev-prop: index = 0
dev-prop: iobase = 0x3f8
dev-prop: irq = 4
dev-prop: chardev = charserial0
isa irq 4
dev: isa-fdc, id ""
dev-prop: driveA = <null>
dev-prop: driveB = <null>
dev-prop: bootindexA = -1
dev-prop: bootindexB = -1
isa irq 6
dev: port92, id ""
dev: vmmouse, id ""
dev: vmport, id ""
dev: i8042, id ""
isa irqs 1,12
dev: isa-pit, id ""
dev-prop: irq = 0
dev-prop: iobase = 0x40
dev: mc146818rtc, id ""
dev-prop: base_year = 2000
dev: i440FX, id ""
bus-prop: addr = 00.0
bus-prop: romfile = <null>
bus-prop: rombar = 1
bus-prop: multifunction = off
bus-prop: command_serr_enable = on
class Host bridge, addr 00:00.0, pci id 8086:1237 (sub 1af4:1100)
dev: ioapic, id ""
gpio-in 24
irq 0
mmio 00000000fec00000/0000000000001000
dev: fw_cfg, id ""
dev-prop: ctl_iobase = 0x510
dev-prop: data_iobase = 0x511
irq 0
mmio ffffffffffffffff/0000000000000002
mmio ffffffffffffffff/0000000000000002
dev: kvmclock, id ""
irq 0
dev: apic, id ""
dev-prop: id = 0
irq 0
mmio 00000000fee00000/0000000000100000


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Monday, January 16, 2012 3:14 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Stefan Hajnoczi; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; qemu-devel
Subject: RE: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server
,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multif
unction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
You're right.
If WdfCmResourceListGetCount returns zero, it must be a problem with resources list.
Output of "info pci" and "info qtree" commands could be helpful in analyzing this problem.

Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Sunday, January 15, 2012 7:42 PM
To: Stefan Hajnoczi
Cc: Charles.Tsai-蔡清海-研究發展部; Alon Levy;
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested Qemu 0.15 for Windows XP guest OS. But I found that the Virtual Serial I/O driver failed in driver initialization.
The root cause of this problem is because the hardware resources(I/O in this device) is not allocated to the virtual serial I/O.
When I debugged on the vioserial driver, no hardware resource actually is allocated to this device.
This bug seems to be in the area of Qemu. Do you know whom I can consult to fix this problem? Please let me know if you know the group or the person.

I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
Please post your QEMU command-line so we can see how the guest is configured.
You mentioned that you debugged the driver and hardware resources
weren't allocated. Do you have a virtio PCI device inside the guest
for this virtio-serial device? Were you able to tell which part of
driver initialization failed (finding the PCI device, mapping its
resources (BARs), etc)?
Stefan

Could you post "pci inf

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I just ran the Qemu monitor to get the PCI information. The information is listed belowe.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

I am sorry that it was my mistake because I did not see there was a PIC device which was created with no device driver installed.
Instead of updating the driver, I ran the hardware installation wizard to install the Vioserial driver.
As such, the system could not install the device for me since it was taken over by another device already.
Thank you for your help and I learned a lot about how a hardware device is virtualized by Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Tuesday, January 17, 2012 5:28 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Stefan Hajnoczi; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; qemu-devel
Subject: RE: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I just ran the Qemu monitor to get the PCI information. The information is listed belowe.
From the listed information, I did not see anything wrong with the BAR0.
-----------

Thank you.

Post by Charles.Tsai-蔡清海-研究發展部

Post by Charles.Tsai-蔡清海-研究發展部
2). In Guest Windows XP OS

SP3?
Can you try reproducing this problem on

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I am sorry that it was my mistake because I did not see there was a PIC device which was created with no device driver installed.
Instead of updating the driver, I ran the hardware installation wizard to install the Vioserial driver.
As such, the system could not install the device for me since it was taken over by another device already.
Thank you for your help and I learned a lot about how a hardware device is virtualized by Qemu.

You're welcome.
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, January 17, 2012 5:28 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: RE: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I just ran the Qemu monitor to get the PCI information. The information is listed belowe.

[Stefan Hajnoczi]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win_xp -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
-drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=17,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0

I tried the virtio-serial pieces with qemu.git and a RHEL6 guest. The
guest was able to see the "com.redhat.spice.0" port. This suggests the
problem was either fixed since QEMU 0.15 or that it only affects the
Windows virtio drivers.

Post by Charles.Tsai-蔡清海-研究發展部
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

I suggest trying qemu-kvm 1.0 or qemu-kvm.git because the issue may have
been fixed since 0.15.

If the issue is still present, you could use git-bisect(1) to find the
commit that caused behavior to change between 0.14 and 0.15.

Stefan

[Charles.Tsai-蔡清海-研究發展部]

Stefan,

We need the spice support in Qemu. Does qemu-kvm 1.0 support for spice?

-----Original Message-----
From: Stefan Hajnoczi [mailto:***@gmail.com]
Sent: Monday, January 16, 2012 4:37 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Vadim Rozenfeld; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; qemu-devel
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server
,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multif
unction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,name=com.redhat.spice.0

I tried the virtio-serial pieces with qemu.git and a RHEL6 guest. The guest was able to see the "com.redhat.spice.0" port. This suggests the problem was either fixed since QEMU 0.15 or that it only affects the Windows virtio drivers.

Post by Charles.Tsai-蔡清海-研究發展部
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

I suggest trying qemu-kvm 1.0 or qemu-kvm.git because the issue may have been fixed since 0.15.

If the issue is still present, you could use git-bisect(1) to find the commit that caused behavior to change between

[Stefan Hajnoczi]

Post by Charles.Tsai-蔡清海-研究發展部
We need the spice support in Qemu. Does qemu-kvm 1.0 support for spice?

I believe so.

Stefan

[=?gb2312?B?Q2hhcmxlcy5Uc2FpLbLMx+W6oy3R0L6/sGzVubK/?=]

Stefan,

Can I replace both vireo-pci.c virtio-serial.h files from Qemu 1.0 source tree?
Both files are to initialize the vioserial device when launching a VM.


-----Original Message-----
From: Stefan Hajnoczi [mailto:***@gmail.com]
Sent: Monday, January 16, 2012 5:49 PM
To: Charles.Tsai-���庣-�о��lչ��
Cc: Vadim Rozenfeld; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-�S���t-�о��lչ��; qemu-devel
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
We need the spice support in Qemu. Does qemu-kvm 1.0 support for spice?

I believe so.

Stefan

[Stefan Hajnoczi]

Post by =?gb2312?B?Q2hhcmxlcy5Uc2FpLbLMx+W6oy3R0L6/sGzVubK/?=
Can I replace both vireo-pci.c virtio-serial.h files from Qemu 1.0 source tree?
Both files are to initialize the vioserial device when launching a VM.

I suspect that will not work due to larger scale refactoring and
changes that have affected the codebase. It's probably best to
recompile the full qemu-kvm 1.0 source release.

Stefan

[Charles.Tsai-蔡清海-研究發展部]

Dominique,



Thank you for your information and we will try it here.



From: Dominique Rodrigues [mailto:***@nanocloud.com]
Sent: Monday, January 16, 2012 5:51 PM
To: Charles.Tsai-蔡枅海-研究癌展郚
Cc: Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究癌展郚; Vadim Rozenfeld; qemu-devel
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15



I currently use qemu-1.0 and I confirm that this version works fine with SPICE.

Regards,


Dominique Rodrigues


<http://www.nanocloud.com>
8, rue Lemercier
75017 Paris
France
standard : [phone]
529 002 743 R.C.S. Paris


Le 16/01/2012 10:32, Charles.Tsai-蔡枅海-研究癌展郚 a écrit :

Stefan,

We need the spice support in Qemu. Does qemu-kvm 1.0 support for spice?

-----Original Message-----
From: Stefan Hajnoczi [mailto:***@gmail.com]
Sent: Monday, January 16, 2012 4:37 PM
To: Charles.Tsai-蔡枅海-研究癌展郚
Cc: Vadim Rozenfeld; Alon Levy; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究癌展郚; qemu-devel
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

On Mon, Jan 16, 2012 at 10:02:22AM +0800, Charles.Tsai-蔡枅海-研究癌展郚 wrote:

Vadim,

Thank you for your prompt reply. Here are the information for our test case.


1) we use the following command line to launch the guest OS


/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server
,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multif
unction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,name=com.redhat.spice.0


I tried the virtio-serial pieces with qemu.git and a RHEL6 guest. The guest was able to see the "com.redhat.spice.0" port. This suggests the problem was either fixed since QEMU 0.15 or that it only affects the Windows virtio drivers.


-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0



2). In Guest Windows XP OS


When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.


VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.

I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);


So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.


I suggest trying qemu-kvm 1.0 or qemu-kvm.git because the issue may have been fixed since 0.15.

If the issue is still present, you could use git-bisect(1) to find the commit that caused behavior to change between 0.14 and 0.15.

Stefan
_______________________________________________
Spice-devel mailing list
Spice-***@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Dominique Rodrigues]

I currently use qemu-1.0 and I confirm that this version works fine with
SPICE.

Regards,


Dominique Rodrigues

nanoClouD <http://www.nanocloud.com>
8, rue Lemercier
75017 Paris
France
standard : [phone]
529 002 743 R.C.S. Paris

Post by Charles.Tsai-蔡清海-研究發展部
Stefan,
We need the spice support in Qemu. Does qemu-kvm 1.0 support for spice?
-----Original Message-----
Sent: Monday, January 16, 2012 4:37 PM
To: Charles.Tsai-蔡枅海-研究癌展郚
Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server
,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multif
unction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,name=com.redhat.spice.0

I tried the virtio-serial pieces with qemu.git and a RHEL6 guest. The guest was able to see the "com.redhat.spice.0" port. This suggests the problem was either fixed since QEMU 0.15 or that it only affects the Windows virtio drivers.

Post by Charles.Tsai-蔡清海-研究發展部
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

I suggest trying qemu-kvm 1.0 or qemu-kvm.git because the issue may have been fixed since 0.15.
If the issue is still present, you could use git-bisect(1) to find the commit that caused behavior to change between 0.14 and 0.15.
Stefan
_______________________________________________
Spice-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Michael Roth]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win_xp -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
-drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=17,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,

What versions of the virtio-win drivers are you using?

I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues with
Windows 7, XP SP3, and Server 2008 R1. XP SP3 works intermittently for
me using RHEL6.0 virtio-win, as well as the drivers at:

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

But I've been getting a mix of issues such as guest hangs, vioser-test
failing to enumerate any virtio-serial devices, or various non-critical
error messages from qemu that seem to coincide with the channel being
open/closed (occasionally resulting in the channel becoming unresponsive).

Do any of these seem similar to the behaviour you're seeing? If so I'll
see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Vadim Rozenfeld]

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name win_xp -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
-drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,fd=17,id=hostnet0
-device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues with
Windows 7, XP SP3, and Server 2008 R1. XP SP3 works intermittently for

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs, vioser-test
failing to enumerate any virtio-serial devices, or various non-critical
error messages from qemu that seem to coincide with the channel being
open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so I'll
see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being installed. After I rebooted the
guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,serv
er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mult
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues
with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs, vioser-test
failing to enumerate any virtio-serial devices, or various
non-critical error messages from qemu that seem to coincide with the
channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

It is SMP system.

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being
installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,se
rv er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,add
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootin
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues
with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to coincide
with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being
installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,se
rv er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,add
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootin
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues
with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to coincide
with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Stefan Hajnoczi]

Post by Charles.Tsai-蔡清海-研究發展部
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being installed. After I rebooted the
guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

If you need to reproduce the installation hang I suggest using qemu
-snapshot or qemu -drive ...,snapshot=on. These options prevent changes
made by the guest to the disk image from being permanent.

Once you terminate QEMU the changes will be gone and your disk image
will be unchanged - useful for repeatedly testing these types of issues!

Stefan

[Alon Levy]

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being installed. After I rebooted the
guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

If you need to reproduce the installation hang I suggest using qemu
-snapshot or qemu -drive ...,snapshot=on. These options prevent changes
made by the guest to the disk image from being permanent.
Once you terminate QEMU the changes will be gone and your disk image
will be unchanged - useful for repeatedly testing these types of issues!

There is an additional "trick" I use, if you add -no-shutdown then if
you find yourself wanting to save the changes anyway (say you started
with -snapshot but decided you want to keep the changes you have done),
which you can do with "commit virtio0" or "commit ide0" (depending on
the block device), it will allow you to do the commit after you shutdown
the guest, which is easier then trying to get it to unmount the disks.

Post by Stefan Hajnoczi
Stefan

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Thank you for your information and we will use it if we need to find the bug next time.

-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 7:26 PM
To: Stefan Hajnoczi
Cc: Charles.Tsai-蔡清海-研究發展部; qemu-devel; Michael Roth; Vadim Rozenfeld; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Stefan Hajnoczi

Post by Charles.Tsai-蔡清海-研究發展部
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

If you need to reproduce the installation hang I suggest using qemu
-snapshot or qemu -drive ...,snapshot=on. These options prevent
changes made by the guest to the disk image from being permanent.
Once you terminate QEMU the changes will be gone and your disk image
will be unchanged - useful for repeatedly testing these types of issues!

There is an additional "trick" I use, if you add -no-shutdown then if you find yourself wanting to save the changes anyway (say you started with -snapshot but decided you want to keep the changes you have done), which you can do with "commit virtio0" or "commit ide0" (depending on the block device), it will allow you to do the commit after you shutdown the guest, which is easier then trying to get it to unmount the disks.

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver being installed. After I rebooted the
guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,serv
er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mult
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0
-spice port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n",
__FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest qemu.git
(1.0). Linux guests work fine, but I've been having various issues
with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs, vioser-test
failing to enumerate any virtio-serial devices, or various
non-critical error messages from qemu that seem to coincide with the
channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

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.

In your previous mail you said,

Post by Alon Levy
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?


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.
2. SPICE server needs to pack the printing raw data in a right format and send it to the spice client.


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:***@redhat.com]
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Cc: spice-***@lists.freedesktop.org; Alex Huang-黃必賢-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.fr

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

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

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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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.
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部

Post by Charles.Tsai-蔡清海-研究發展部

Post by Alon Levy

Post by Charles.Tsai-蔡清海-研究發展部
===============================

Thank you for your suggest. If we specify the logical channel name in qemu command line such as "com.redhat.spice.printer.0", the Windows application can open such a device and use it without changing any line code. Normally, the logical name of a device is exposed from a device driver in Windows. This is a puzzle to me. But I will try and debug it to see if it works or not. In our implementation, there is only one printing channel per VM.

<<<<<====================================

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部

Post by Charles.Tsai-蔡清海-研究發展部

Post by Alon Levy

Post by Charles.Tsai-蔡清海-研究發展部

Post by Charles.Tsai-蔡清海-工程部

Post by Charles.Tsai-蔡清海-研究發展部
============================

The selection of the local printer is based on configuration policy. It is not like the USB redirection expose all local printers to Windows guest OS.
<<<================================

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-研究發展部
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

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




-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Thanks. Your additional information will help me a lot when I debug the code.
I don't expect my code to work without tracing and debugging the code.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

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:***@redhat.com]
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used
transport, which is now deprecated? also, if you look at the actual
usage of it you will see that those two devices are tested in some order
for existance, and only one is actually used.

In short: these are two implementations of the guest<->host pipe,
vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from
guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.

In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,

looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from
guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-deve
l

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Yes, I did see these. But I think this device is no longer used by the service.
That is why I want to clarify my puzzle.


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, March 13, 2012 5:27 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,

looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-de
ve
l

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Yes, I did see these. But I think this device is no longer used by the service.
That is why I want to clarify my puzzle.

Charles, the puzzle is simple: it isn't being used anymore. You don't
create the device, vdagent fails to CreateFile, and moves on to use the
virtio serial port.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 5:27 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from
guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-de
ve
l

[Charles.Tsai-蔡清海-研究發展部]

Thanks. I got it now. How come the code is still there.
I believe that CreateFile API fails definitely because there is no such a device in the system.


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, March 13, 2012 6:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Yes, I did see these. But I think this device is no longer used by the service.
That is why I want to clarify my puzzle.

Charles, the puzzle is simple: it isn't being used anymore. You don't create the device, vdagent fails to CreateFile, and moves on to use the virtio serial port.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 5:27 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network
printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-
de

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Thanks. I got it now. How come the code is still there.

Because the same code base is for guests using the new virtserialport
and the old vdi_port. That device is still in RHEL 5.

Post by Charles.Tsai-蔡清海-研究發展部
I believe that CreateFile API fails definitely because there is no such a device in the system.
-----Original Message-----
Sent: Tuesday, March 13, 2012 6:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Yes, I did see these. But I think this device is no longer used by the service.
That is why I want to clarify my puzzle.

Charles, the puzzle is simple: it isn't being used anymore. You don't create the device, vdagent fails to CreateFile, and moves on to use the virtio serial port.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 5:27 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer from
guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network
printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spice-
de
ve
l

[Charles.Tsai-蔡清海-研究發展部]

Thanks. Otherwise, I cannot get it when I read Windows service code.

-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, March 13, 2012 7:09 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Thanks. I got it now. How come the code is still there.

Because the same code base is for guests using the new virtserialport and the old vdi_port. That device is still in RHEL 5.

Post by Charles.Tsai-蔡清海-研究發展部
I believe that CreateFile API fails definitely because there is no such a device in the system.
-----Original Message-----
Sent: Tuesday, March 13, 2012 6:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Yes, I did see these. But I think this device is no longer used by the service.
That is why I want to clarify my puzzle.

Charles, the puzzle is simple: it isn't being used anymore. You don't create the device, vdagent fails to CreateFile, and moves on to use the virtio serial port.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 5:27 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your clarification. I did not see VDI_PORT_DEV_NAME is being used in the service.

win32-vdagent alon (master)$ git grep VDI_PORT_DEV_NAME
vdservice/pci_vdi_port.cpp:#define VDI_PORT_DEV_NAME TEXT("\\\\.\\VDIPort")
vdservice/pci_vdi_port.cpp: _handle = CreateFile(VDI_PORT_DEV_NAME, GENERIC_READ | GENERIC_WRITE, 0, NULL,
looking at git://anongit.freedesktop.org/spice/win32/vd_agent

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Tuesday, March 13, 2012 4:06 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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?

Isn't there any comment saying that vdi_port is the RHEL 5 used transport, which is now deprecated? also, if you look at the actual usage of it you will see that those two devices are tested in some order for existance, and only one is actually used.
In short: these are two implementations of the guest<->host pipe, vdi_port is the older one and not used anymore, you can ignore it.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 6:08 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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

spice/server/reds.c: spice_server_char_device_add_interface
spicevmc_device_connect
Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 12, 2012 3:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Thank you for your prompt response. Please see my comments below inside the pair tag "Charles>>>> <<<Charles"
-----Original Message-----
Sent: Saturday, March 10, 2012 6:35 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Spice-devel] Access local network printer from guest OS

Post by Charles.Tsai-蔡清海-研究發展部
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).

Post by Charles.Tsai-蔡清海-研究發展部
In your previous mail you said,

Post by Alon Levy
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.

Post by Charles.Tsai-蔡清海-研究發展部
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.printer.0"
Would you have one per printer?

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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

Post by Charles.Tsai-蔡清海-研究發展部
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?

Post by Charles.Tsai-蔡清海-研究發展部
<<<Charles

Post by Charles.Tsai-蔡清海-研究發展部
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-----
Sent: Monday, January 02, 2012 7:49 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Alon Levy
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.

Post by Alon Levy
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).

Post by Alon Levy
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.

Post by Alon Levy
-----Original Message-----
Sent: Monday, January 02, 2012 6:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network printer
from guest OS

Post by Charles.Tsai-蔡清海-工程部
Alon,
Let me recap what you suggest in case that I missed your point.

sure.

Post by Charles.Tsai-蔡清海-工程部
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.

Post by Charles.Tsai-蔡清海-工程部
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.

-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,
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.

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 10:19 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network
printer from guest OS

Post by Charles.Tsai-蔡清海-工程部
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.

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.
- no, you don't need to create a new virtual I/O channel, virtioserial
is just the virtual I/O you need.
HTH
Alon

Post by Charles.Tsai-蔡清海-工程部
-----Original Message-----
Sent: Sunday, January 01, 2012 7:45 PM
To: Charles.Tsai-蔡清海-工程部
Subject: Re: [Spice-devel] Access local network
printer from guest OS

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.
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
qemu initiated (guest did something to the virtual printer device)
client initiated (callback set during channel creation, in inputs
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
http://lists.freedesktop.org/mailman/listinfo/spic
e-
de
ve
l

[Charles.Tsai-蔡清海-研究發展部]

Alon,

I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.

If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.

-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"

Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?

Let me know if I made anything wrong with my Qemu's command options. Thanks.
==================================

#!/bin/sh

ARGS="-localtime -spice port=5900,disable-ticketing \
-drive file=/opt/virt/user/Win7_64.cow \
-vga qxl \
-device virtio-serial-pci,multifunction=on \
-chardev spicevmc,id=vdagent,id=vdagent,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-usbdevice tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdpr

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is
that there is a function qemu calls to get the allowed list of names by
spice-server. That function is implemented by spice-server, so you would
need to add the "vdprint" string to it.

diff --git a/server/reds.c b/server/reds.c
index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};

Then you need to tell spice what to do when
spice_server_char_device_add_interface is called with this subtype
(subtype == 'name' parameter to the chardev. Another thing that should
be changed).

You could basically just use another spicevmc_device_connect call. You
will need to add the channel to the spice.proto (again, this should be
changed so adding generic channels doesn't require this - something like
having a generic channel subtype, and having a message that tells the
client which channel this is - will be a little ugly since getting a
channel list won't be enough for the client to know what channels are
available, but it's not too bad - anyway off topic)

For now you can just change the spice-protocol/spice/enums.h file
directly instead of recreating it:

U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff
diff --git a/spice/enums.h b/spice/enums.h
index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,

SPICE_END_CHANNEL
};

@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}

Hope you can understand my not very collected response.

Bonus points for sending patches to fix the raised issues, or starting a
discussion on how to exactly.

Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \
-drive file=/opt/virt/user/Win7_64.cow \
-vga qxl \
-device virtio-serial-pci,multifunction=on \
-chardev spicevmc,id=vdagent,id=vdagent,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-usbdevice tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"

[Charles.Tsai-蔡清海-研究發展部]

Alon,

I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.

diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};

Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).

You could basically just use another spicevmc_device_connect call. You will need to add the channel to the spice.proto (again, this should be changed so adding generic channels doesn't require this - something like having a generic channel subtype, and having a message that tells the client which channel this is - will be a little ugly since getting a channel list won't be enough for the client to know what channels are available, but it's not too bad - anyway off topic)

For now you can just change the spice-protocol/spice/enums.h file directly instead of recreating it:

U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff --git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,

SPICE_END_CHANNEL
};

@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}

Hope you can understand my not very collected response.

Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.

Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice
tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \ -device
virtserialport,chardev=vdprint,name=co

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.

OK. So nothing comes to mind. Where is it stuck?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};
Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
You could basically just use another spicevmc_device_connect call. You will need to add the channel to the spice.proto (again, this should be changed so adding generic channels doesn't require this - something like having a generic channel subtype, and having a message that tells the client which channel this is - will be a little ugly since getting a channel list won't be enough for the client to know what channels are available, but it's not too bad - anyway off topic)
U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff --git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,
SPICE_END_CHANNEL
};
@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}
Hope you can understand my not very collected response.
Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice
tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \ -device
virtserialport,chardev=vdprint,name=com.redhat.print.0"

[Charles.Tsai-蔡清海-研究發展部]

Alon,

I will put some traces in Qemu to see if I can find out where the code is stuck.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Thursday, March 22, 2012 10:22 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.

OK. So nothing comes to mind. Where is it stuck?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};
Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
You could basically just use another spicevmc_device_connect call. You
will need to add the channel to the spice.proto (again, this should be
changed so adding generic channels doesn't require this - something
like having a generic channel subtype, and having a message that tells
the client which channel this is - will be a little ugly since getting
a channel list won't be enough for the client to know what channels
are available, but it's not too bad - anyway off topic)
U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff
--git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,
SPICE_END_CHANNEL
};
@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}
Hope you can understand my not very collected response.
Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice
tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \ -device
virtserialport,chardev=vdprint,name=com.redhat.pri

[Charles.Tsai-蔡清海-研究發展部]

Alon,

In Windows, driver name is provided by the device driver. In this case , "com.redhat.print.0" is the device visible to application.
Because device "com.redhat.print.0" is created by the Qemu which is in Linux, how the Linux passes the driver information to Windows
So that Windows application can open it.

When I observed the trace of the spice server, I found vdagent seems to be created after Windows viritio driver is loaded.
In other words, the creation of vdagent device seems to be triggered by the Windows OS other than from the qemu command line.
By the same token, "vdprint" should be created after "com.redhat.print.0" is loaded by Windows OS.

So far, I am still looking at the link between "vdprint" and "com.redhat.print.0". It looks like the virioserial driver must be modified.
Otherwise, how the Windows application can see such a device?


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Thursday, March 22, 2012 10:22 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.

OK. So nothing comes to mind. Where is it stuck?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};
Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
You could basically just use another spicevmc_device_connect call. You
will need to add the channel to the spice.proto (again, this should be
changed so adding generic channels doesn't require this - something
like having a generic channel subtype, and having a message that tells
the client which channel this is - will be a little ugly since getting
a channel list won't be enough for the client to know what channels
are available, but it's not too bad - anyway off topic)
U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff
--git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,
SPICE_END_CHANNEL
};
@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}
Hope you can understand my not very collected response.
Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice
tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \ -device
virtseria

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In Windows, driver name is provided by the device driver. In this case , "com.redhat.print.0" is the device visible to application.
Because device "com.redhat.print.0" is created by the Qemu which is in Linux, how the Linux passes the driver information to Windows
So that Windows application can open it.
When I observed the trace of the spice server, I found vdagent seems to be created after Windows viritio driver is loaded.
In other words, the creation of vdagent device seems to be triggered by the Windows OS other than from the qemu command line.
By the same token, "vdprint" should be created after "com.redhat.print.0" is loaded by Windows OS.
So far, I am still looking at the link between "vdprint" and "com.redhat.print.0". It looks like the virioserial driver must be modified.
Otherwise, how the Windows application can see such a device?

For vdagent, what you have is:
qemu virtio serial bus pci device
qemu virtio serial port named "com.redhat.spice.0"
guest virtio serial pci driver
guest vdservice.exe
guest vdagent.exe

Guest startup:
loads virtio serial pci driver.
-> creates a device file for named "com.redhat.spice.0"
starts vdservice.exe
-> opens the file "com.redhat.spice.0"
starts vdagent.exe

So for the printer driver I imagined you would have a printer driver,
vdprint.sys, that would do the same as vdservice.exe, i.e.

Setup:
virtio serial bus
virtio serial port "com.redhat.print.0"
guest virtio serial pci driver
guest vdprinter driver (needs to make sure this loads after virtio)

Startup:
load virtio serial pci driver
load vdprinter driver

Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 10:22 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.

OK. So nothing comes to mind. Where is it stuck?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};
Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
You could basically just use another spicevmc_device_connect call. You
will need to add the channel to the spice.proto (again, this should be
changed so adding generic channels doesn't require this - something
like having a generic channel subtype, and having a message that tells
the client which channel this is - will be a little ugly since getting
a channel list won't be enough for the client to know what channels
are available, but it's not too bad - anyway off topic)
U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff
--git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,
SPICE_END_CHANNEL
};
@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}
Hope you can understand my not very collected response.
Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \ -usbdevice
tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \ -device
virtserialport,chardev=vdprint,name=com.redhat.print.0"

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Thank you for information.

In order isolate the issue, I simply just ran the following script to create the printing channel.
Initially, I disable the Virio serial adapter. When I enable the Virtio serial adapter, the Windows is totally locked up.
I am going to debug the Windows virtio serial driver to see if I can find something there or not.

To my understanding, the creation of vdagent and vdprint should be similar inside the Qemu. I do not know why the system is locked after I enable the vireo serial PCI adapter.
====================

ARGS="-localtime -spice port=5900,disable-ticketing \
-drive file=/opt/virt/user/Win7_64.cow \
-vga qxl \
-device virtio-serial-pci \
-usbdevice tablet -smp 1,cores=2 -m 2048 -enable-kvm \
-net nic -net user \
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Friday, March 23, 2012 5:03 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In Windows, driver name is provided by the device driver. In this case , "com.redhat.print.0" is the device visible to application.
Because device "com.redhat.print.0" is created by the Qemu which is in
Linux, how the Linux passes the driver information to Windows So that Windows application can open it.
When I observed the trace of the spice server, I found vdagent seems to be created after Windows viritio driver is loaded.
In other words, the creation of vdagent device seems to be triggered by the Windows OS other than from the qemu command line.
By the same token, "vdprint" should be created after "com.redhat.print.0" is loaded by Windows OS.
So far, I am still looking at the link between "vdprint" and "com.redhat.print.0". It looks like the virioserial driver must be modified.
Otherwise, how the Windows application can see such a device?

For vdagent, what you have is:
qemu virtio serial bus pci device
qemu virtio serial port named "com.redhat.spice.0"
guest virtio serial pci driver
guest vdservice.exe
guest vdagent.exe

Guest startup:
loads virtio serial pci driver.
-> creates a device file for named "com.redhat.spice.0"
starts vdservice.exe
-> opens the file "com.redhat.spice.0"
starts vdagent.exe

So for the printer driver I imagined you would have a printer driver, vdprint.sys, that would do the same as vdservice.exe, i.e.

Setup:
virtio serial bus
virtio serial port "com.redhat.print.0"
guest virtio serial pci driver
guest vdprinter driver (needs to make sure this loads after virtio)

Startup:
load virtio serial pci driver
load vdprinter driver

Alon

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 10:22 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I did all of what you mentioned before. Nothing is missed in my checklist.
Function "spice_server_char_device_add_interface" in fact is not called at all.
Qemu somehow is blocked somewhere. For now, I still do not know the root cause.

OK. So nothing comes to mind. Where is it stuck?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, March 22, 2012 9:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Fail to create a printing channel

Post by Charles.Tsai-蔡清海-研究發展部
Alon,

Or anyone else on the list..

Post by Charles.Tsai-蔡清海-研究發展部
I am running the following script to create the printing channel based on the virtio device framework.
When the VM is launched, it seems to block somewhere in Qemu.
If I remove the following two lines, the VM can be launched without any problem.
The following two lines basically are used to create the printing channel between the host and guest.
-chardev spicevmc,id=vdprint,name=vdprint \
-device virtserialport,chardev=vdprint,name=com.redhat.print.0"
Can you give me some hits why Qemu does not call spice server to create the printing channel? Is there any function in Qemu I need to change so as to create additional channel within the Virtio device?
Let me know if I made anything wrong with my Qemu's command options. Thanks.

How it works right now, and it's probably not how we want it to be, is that there is a function qemu calls to get the allowed list of names by spice-server. That function is implemented by spice-server, so you would need to add the "vdprint" string to it.
diff --git a/server/reds.c b/server/reds.c index c54d30c..bb75624 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3364,6 +3364,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,
@@ -3371,6 +3372,7 @@ const char *spice_server_char_device_recognized_subtypes_list[] = {
SUBTYPE_SMARTCARD,
#endif
SUBTYPE_USBREDIR,
+ SUBTYPE_PRINTER,
NULL,
};
Then you need to tell spice what to do when spice_server_char_device_add_interface is called with this subtype (subtype == 'name' parameter to the chardev. Another thing that should be changed).
You could basically just use another spicevmc_device_connect call.
You will need to add the channel to the spice.proto (again, this
should be changed so adding generic channels doesn't require this -
something like having a generic channel subtype, and having a
message that tells the client which channel this is - will be a
little ugly since getting a channel list won't be enough for the
client to know what channels are available, but it's not too bad -
anyway off topic)
U x86_64 garlic:spice-protocol alon ((1a3b563...))$ git diff diff
--git a/spice/enums.h b/spice/enums.h index d2dbfd0..9f54ac0 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -330,6 +330,7 @@ enum {
SPICE_CHANNEL_TUNNEL,
SPICE_CHANNEL_SMARTCARD,
SPICE_CHANNEL_USBREDIR,
+ SPICE_CHANNEL_PRINTER,
SPICE_END_CHANNEL
};
@@ -3401,9 +3403,13 @@ static int spice_server_char_device_add_interface(SpiceServer *s,
}
}
#endif
+ /* all other channels use the generic spicevmc channel */
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;
}
Hope you can understand my not very collected response.
Bonus points for sending patches to fix the raised issues, or starting a discussion on how to exactly.
Alon

Post by Charles.Tsai-蔡清海-研究發展部
==================================
#!/bin/sh
ARGS="-localtime -spice port=5900,disable-ticketing \ -drive
file=/opt/virt/user/Win7_64.cow \ -vga qxl \ -device
virtio-serial-pci,multifunction=on \ -chardev
spicevmc,id=vdagent,id=vdagent,name=vdagent \ -device
virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-usbdevice tablet -smp 1,cores=2 -m 2048 -enable-kvm -net nic -net
user \ -chardev spicevmc,id=vdprint,name=vdprint \ -device
virtserialport,chardev=vdprint,name=com.redhat.print

[Charles.Tsai-蔡清海-研究發展部]

Alon,

I read the spice code and found a spice tunnel channel there. What is the purpose of the tunnel channel? Is it for network tunneling?
What is the use case for

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I read the spice code and found a spice tunnel channel there. What is the purpose of the tunnel channel? Is it for network tunneling?
What is the use case for tunnel channel in spice?

Yes, it is for network tunneling. But it isn't enabled by default and it
has bit rotted probably.

Alon

[Charles.Tsai-蔡清海-研究發展部]

Alon,

My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?

In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?

=======================================================================================
struct SpiceCharDeviceState vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup,
};


void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin)
{
while (read_from_vdi_port());

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Cc: spice-***@lists.freedesktop.org
Subject: Read data out of the Virtqueue

Alon,

My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?

In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?

=======================================================================================
struct SpiceCharDeviceState vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };


void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the
vdservice issue? Is it a bug in the original or just in the one you
modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
=======================================================================================
struct SpiceCharDeviceState vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_from_vdi_port());
}

[Charles.Tsai-蔡清海-研究發展部]

Alon,

It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
======================================================================
================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInst

[Charles.Tsai-蔡清海-研究發展部]

Alon,

In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client

void RedClient::handle_channels(RedPeer::InMessage* message)
{
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}

For the printing channel, it is created and registered by function spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file)
Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.
Can you tell me how to resolve this problem based on the spice architecture? Thanks.


-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Cc: spice-***@lists.freedesktop.org
Subject: RE: Read data out of the Virtqueue

Alon,

It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.


-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
======================================================================
================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_fr

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client
void RedClient::handle_channels(RedPeer::InMessage* message)
{
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}
For the printing channel, it is created and registered by function spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file)
Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.

Two things: First, you are using the old client code base as an example.
All well and good, but if possible it's better to use spice-gtk as a
base for new features, because that's the client we are going with
forwward (or actually the client enabling library, with remote-viewer
being the preffered client).
Second, what do you mean registered after the spice client is up? If
there is some race window where the server is already listening to
clients but the printing channel is not registered, that is bad and
needs fixing, but in general the server is initialized *before* the
client is connected. The right order is
1. server channels are registered
2. server starts listening
3. client connects

#3 cannot come before #2 so in general there is no way to have the
situation you describe (unless there is a race and #1 happens after #2
and then both orders with respect to #3 are possible).

Post by Charles.Tsai-蔡清海-研究發展部
Can you tell me how to resolve this problem based on the spice architecture? Thanks.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Subject: RE: Read data out of the Virtqueue
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.
-----Original Message-----
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
======================================================================
================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_from_vdi_port());
}

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Our Windows client code is based on 0.10.1 release and that is, I believe, the latest one.
"spice-gtk" is running in LINUX and I believe it is not applicable to Windows platform.


Please refer to the following trace to understand what I said. As you can see, printing channel is registered to spice server after the following trace
"spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT".

Spice server report the number of channels to the client using the following main channel message "SPICE_MSG_MAIN_CHANNELS_LIST" that happens before the printing channel registers to the spice server. As such, the spice client cannot create the "print channel object" when it is launched.

I am thinking to remedy such a problem by sending a message to spice client thru the main channel. After spice client receives that message, it creates and initialize the "printing object". Although it is not good approach, it is the easy way to fix this issue for us. Let me know if you have a better idea. Thanks.

==================================================================================================================================
***@ctsai-ubuntu:~$ ./Target32.sh
Starting QEMU with...
-localtime -drive file=/var/lib/libvirt/images/Windows-7-32.img -vga qxl -spice port=5900,disable-ticketing -device virtio-serial-pci,ioeventfd=off -chardev spicevmc,id=vdagent,name=vdagent,debug=2 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdprint,name=vdprint,debug=2 -device virtserialport,chardev=vdprint,name=com.redhat.print.0 -smp 1,cores=2 -m 2048 -enable-kvm
....
do_spice_init: starting 0.10.1
spice_server_add_interface: spice_server_add_interface: type=migration

spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: spice_server_add_interface: type=keyboard

spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: spice_server_add_interface: type=mouse

spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: spice_server_add_interface: type=qxl

spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
display_channel_create: create display channel
cursor_channel_create: create cursor channel
scd: 1: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device

spice_server_char_device_add_interface: CHAR_DEVICE vdagent
scd: 2: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device

spice_server_char_device_add_interface: CHAR_DEVICE vdprint
spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT
spice_chr_write
scd: 1: spice_chr_write: 36
scd: 1: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 2: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 3: vmc_read: vdagent (nil) 8/0/0
scd: 4: vmc_read: vdagent (nil) 8/0/0
spice_chr_write
scd: 2: spice_chr_write: 36
scd: 5: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 6: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 7: vmc_read: vdagent (nil) 8/0/0
scd: 8: vmc_read: vdagent (nil) 8/0/0




-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, April 03, 2012 3:54 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client
void RedClient::handle_channels(RedPeer::InMessage* message) {
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}
For the printing channel, it is created and registered by function
spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file) Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.

Two things: First, you are using the old client code base as an example.
All well and good, but if possible it's better to use spice-gtk as a base for new features, because that's the client we are going with forwward (or actually the client enabling library, with remote-viewer being the preffered client).
Second, what do you mean registered after the spice client is up? If there is some race window where the server is already listening to clients but the printing channel is not registered, that is bad and needs fixing, but in general the server is initialized *before* the client is connected. The right order is 1. server channels are registered 2. server starts listening 3. client connects

#3 cannot come before #2 so in general there is no way to have the situation you describe (unless there is a race and #1 happens after #2 and then both orders with respect to #3 are possible).

Post by Charles.Tsai-蔡清海-研究發展部
Can you tell me how to resolve this problem based on the spice architecture? Thanks.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Subject: RE: Read data out of the Virtqueue
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.
-----Original Message-----
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
====================================================================
== ================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_from_vdi_port(

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Our Windows client code is based on 0.10.1 release and that is, I believe, the latest one.
"spice-gtk" is running in LINUX and I believe it is not applicable to Windows platform.

That is wrong. It works on windows as well, there is also a prebuilt
binary on http://www.spice-space.org/downloads.html of remote-viewer.exe

Post by Charles.Tsai-蔡清海-研究發展部
Please refer to the following trace to understand what I said. As you can see, printing channel is registered to spice server after the following trace
"spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT".
Spice server report the number of channels to the client using the following main channel message "SPICE_MSG_MAIN_CHANNELS_LIST" that happens before the printing channel registers to the spice server. As such, the spice client cannot create the "print channel object" when it is launched.

ok, my bad. The problem is not a race, the problem is that the channel
only gets registered when the guest opens the device, not during
initialization of the vm (before it starts running, and before spice
server listens to connections).

The channel is registered via spice_server_add_interface:
spice_server_add_interface
-> spice_server_char_device_add_interface
-> spicevmc_device_connect
-> reds_register_channel

spice_server_add_interface is called by qemu:
spice_chr_guest_open / spice_chr_write
-> vmc_register_interface
-> qemu_spice_add_interface
-> spice_server_add_interface

So one way would be to get spice_chr_guest_open to be called early.
We could have the initialization of the channel done unconditionally
during chardev creation. The way it should affect users:
usbredir - already triggers the channel creation via doing a
smartcard - I think it does the same as usbredir.
vdagent - can't do it, server uses the interface registration as guest
agent exists. So will have to special case.

qemu_chr_fe_open in usbredir_initfn (see hw/usb/redirect.c)
vdagent - doesn't have a dedicated channel so not really a problem.

Post by Charles.Tsai-蔡清海-研究發展部
I am thinking to remedy such a problem by sending a message to spice client thru the main channel. After spice client receives that message, it creates and initialize the "printing object". Although it is not good approach, it is the easy way to fix this issue for us. Let me know if you have a better idea. Thanks.

So I guess something like the following would be a better solution:

diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 1e735ff..d3ae0b7 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -226,12 +226,14 @@ CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
chr->chr_guest_open = spice_chr_guest_open;
chr->chr_guest_close = spice_chr_guest_close;

-#if SPICE_SERVER_VERSION < 0x000901
- /* See comment in vmc_state() */
if (strcmp(subtype, "vdagent") == 0) {
+#if SPICE_SERVER_VERSION < 0x000901
+ /* See comment in vmc_state() */
qemu_chr_generic_open(chr);
- }
#endif
+ } else {
+ vmc_register_interface(s);
+ }

return chr;
}


Hans, any comments?

Post by Charles.Tsai-蔡清海-研究發展部
==================================================================================================================================
Starting QEMU with...
-localtime -drive file=/var/lib/libvirt/images/Windows-7-32.img -vga qxl -spice port=5900,disable-ticketing -device virtio-serial-pci,ioeventfd=off -chardev spicevmc,id=vdagent,name=vdagent,debug=2 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdprint,name=vdprint,debug=2 -device virtserialport,chardev=vdprint,name=com.redhat.print.0 -smp 1,cores=2 -m 2048 -enable-kvm
....
do_spice_init: starting 0.10.1
spice_server_add_interface: spice_server_add_interface: type=migration
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: spice_server_add_interface: type=keyboard
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: spice_server_add_interface: type=mouse
spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: spice_server_add_interface: type=qxl
spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
display_channel_create: create display channel
cursor_channel_create: create cursor channel
scd: 1: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdagent
scd: 2: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdprint
spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT
spice_chr_write
scd: 1: spice_chr_write: 36
scd: 1: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 2: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 3: vmc_read: vdagent (nil) 8/0/0
scd: 4: vmc_read: vdagent (nil) 8/0/0
spice_chr_write
scd: 2: spice_chr_write: 36
scd: 5: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 6: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 7: vmc_read: vdagent (nil) 8/0/0
scd: 8: vmc_read: vdagent (nil) 8/0/0
-----Original Message-----
Sent: Tuesday, April 03, 2012 3:54 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client
void RedClient::handle_channels(RedPeer::InMessage* message) {
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}
For the printing channel, it is created and registered by function
spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file) Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.

Two things: First, you are using the old client code base as an example.
All well and good, but if possible it's better to use spice-gtk as a base for new features, because that's the client we are going with forwward (or actually the client enabling library, with remote-viewer being the preffered client).
Second, what do you mean registered after the spice client is up? If there is some race window where the server is already listening to clients but the printing channel is not registered, that is bad and needs fixing, but in general the server is initialized *before* the client is connected. The right order is 1. server channels are registered 2. server starts listening 3. client connects
#3 cannot come before #2 so in general there is no way to have the situation you describe (unless there is a race and #1 happens after #2 and then both orders with respect to #3 are possible).

Post by Charles.Tsai-蔡清海-研究發展部
Can you tell me how to resolve this problem based on the spice architecture? Thanks.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Subject: RE: Read data out of the Virtqueue
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.
-----Original Message-----
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
====================================================================
== ================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_from_vdi_port());
}

[Alon Levy]

Post by Alon Levy

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Our Windows client code is based on 0.10.1 release and that is, I believe, the latest one.
"spice-gtk" is running in LINUX and I believe it is not applicable to Windows platform.

That is wrong. It works on windows as well, there is also a prebuilt
binary on http://www.spice-space.org/downloads.html of remote-viewer.exe

Post by Charles.Tsai-蔡清海-研究發展部
Please refer to the following trace to understand what I said. As you can see, printing channel is registered to spice server after the following trace
"spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT".
Spice server report the number of channels to the client using the following main channel message "SPICE_MSG_MAIN_CHANNELS_LIST" that happens before the printing channel registers to the spice server. As such, the spice client cannot create the "print channel object" when it is launched.

ok, my bad. The problem is not a race, the problem is that the channel
only gets registered when the guest opens the device, not during
initialization of the vm (before it starts running, and before spice
server listens to connections).
spice_server_add_interface
-> spice_server_char_device_add_interface
-> spicevmc_device_connect
-> reds_register_channel
spice_chr_guest_open / spice_chr_write
-> vmc_register_interface
-> qemu_spice_add_interface
-> spice_server_add_interface
So one way would be to get spice_chr_guest_open to be called early.
We could have the initialization of the channel done unconditionally
usbredir - already triggers the channel creation via doing a
smartcard - I think it does the same as usbredir.
vdagent - can't do it, server uses the interface registration as guest
agent exists. So will have to special case.
vdagent - doesn't have a dedicated channel so not really a problem.

Eek, somehow I mangled the above paragraph. It should read:

usbredir - already triggers the channel creation via doing a
qemu_chr_fe_open in usbredir_initfn (see hw/usb/redirect.c)

vdagent - can't do it, server uses the interface registration as guest
agent exists. So will have to special case.

Post by Alon Levy

Post by Charles.Tsai-蔡清海-研究發展部
I am thinking to remedy such a problem by sending a message to spice client thru the main channel. After spice client receives that message, it creates and initialize the "printing object". Although it is not good approach, it is the easy way to fix this issue for us. Let me know if you have a better idea. Thanks.

diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 1e735ff..d3ae0b7 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -226,12 +226,14 @@ CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
chr->chr_guest_open = spice_chr_guest_open;
chr->chr_guest_close = spice_chr_guest_close;
-#if SPICE_SERVER_VERSION < 0x000901
- /* See comment in vmc_state() */
if (strcmp(subtype, "vdagent") == 0) {
+#if SPICE_SERVER_VERSION < 0x000901
+ /* See comment in vmc_state() */
qemu_chr_generic_open(chr);
- }
#endif
+ } else {
+ vmc_register_interface(s);
+ }
return chr;
}
Hans, any comments?

Post by Charles.Tsai-蔡清海-研究發展部
==================================================================================================================================
Starting QEMU with...
-localtime -drive file=/var/lib/libvirt/images/Windows-7-32.img -vga qxl -spice port=5900,disable-ticketing -device virtio-serial-pci,ioeventfd=off -chardev spicevmc,id=vdagent,name=vdagent,debug=2 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdprint,name=vdprint,debug=2 -device virtserialport,chardev=vdprint,name=com.redhat.print.0 -smp 1,cores=2 -m 2048 -enable-kvm
....
do_spice_init: starting 0.10.1
spice_server_add_interface: spice_server_add_interface: type=migration
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: spice_server_add_interface: type=keyboard
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: spice_server_add_interface: type=mouse
spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: spice_server_add_interface: type=qxl
spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
display_channel_create: create display channel
cursor_channel_create: create cursor channel
scd: 1: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdagent
scd: 2: vmc_register_interface
spice_server_add_interface: spice_server_add_interface: type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdprint
spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT
spice_chr_write
scd: 1: spice_chr_write: 36
scd: 1: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 2: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 3: vmc_read: vdagent (nil) 8/0/0
scd: 4: vmc_read: vdagent (nil) 8/0/0
spice_chr_write
scd: 2: spice_chr_write: 36
scd: 5: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 6: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 7: vmc_read: vdagent (nil) 8/0/0
scd: 8: vmc_read: vdagent (nil) 8/0/0
-----Original Message-----
Sent: Tuesday, April 03, 2012 3:54 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client
void RedClient::handle_channels(RedPeer::InMessage* message) {
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}
For the printing channel, it is created and registered by function
spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file) Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.

Two things: First, you are using the old client code base as an example.
All well and good, but if possible it's better to use spice-gtk as a base for new features, because that's the client we are going with forwward (or actually the client enabling library, with remote-viewer being the preffered client).
Second, what do you mean registered after the spice client is up? If there is some race window where the server is already listening to clients but the printing channel is not registered, that is bad and needs fixing, but in general the server is initialized *before* the client is connected. The right order is 1. server channels are registered 2. server starts listening 3. client connects
#3 cannot come before #2 so in general there is no way to have the situation you describe (unless there is a race and #1 happens after #2 and then both orders with respect to #3 are possible).

Post by Charles.Tsai-蔡清海-研究發展部
Can you tell me how to resolve this problem based on the spice architecture? Thanks.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Subject: RE: Read data out of the Virtqueue
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.
-----Original Message-----
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
====================================================================
== ================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {
while (read_from_vdi_port());
}

_______________________________________________
Spice-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Alon,

Do you recommend us to use the new spice client code from "http://www.spice-space.org/downloads.html" link?
I will try to use it latter on to see what it is difference.

You are right. The printing channel is created when the guest OS opens the virtIO printing channel. That is why it happens so lately.
From your last reply, it looks the printing channel must be handled specially so that the spice client can create the object.

I am writing the code to notify the spice client right after the printing channel is UP. This is the less code to change to make it work.



-----Original Message-----
From: Alon Levy [mailto:***@redhat.com]
Sent: Tuesday, April 03, 2012 5:18 PM
To: Hans de Goede; Charles.Tsai-蔡清海-研究發展部
Cc: spice-***@lists.freedesktop.org
Subject: [RFC] register vmc interface early for name != vdagent [was: Re: Read data out of the Virtqueue]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Our Windows client code is based on 0.10.1 release and that is, I believe, the latest one.
"spice-gtk" is running in LINUX and I believe it is not applicable to Windows platform.

That is wrong. It works on windows as well, there is also a prebuilt binary on http://www.spice-space.org/downloads.html of remote-viewer.exe

Post by Charles.Tsai-蔡清海-研究發展部
Please refer to the following trace to understand what I said. As you
can see, printing channel is registered to spice server after the
following trace
"spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT".
Spice server report the number of channels to the client using the following main channel message "SPICE_MSG_MAIN_CHANNELS_LIST" that happens before the printing channel registers to the spice server. As such, the spice client cannot create the "print channel object" when it is launched.

ok, my bad. The problem is not a race, the problem is that the channel only gets registered when the guest opens the device, not during initialization of the vm (before it starts running, and before spice server listens to connections).

The channel is registered via spice_server_add_interface:
spice_server_add_interface
-> spice_server_char_device_add_interface
-> spicevmc_device_connect
-> reds_register_channel

spice_server_add_interface is called by qemu:
spice_chr_guest_open / spice_chr_write
-> vmc_register_interface
-> qemu_spice_add_interface
-> spice_server_add_interface

So one way would be to get spice_chr_guest_open to be called early.
We could have the initialization of the channel done unconditionally during chardev creation. The way it should affect users:
usbredir - already triggers the channel creation via doing a smartcard - I think it does the same as usbredir.
vdagent - can't do it, server uses the interface registration as guest agent exists. So will have to special case.

qemu_chr_fe_open in usbredir_initfn (see hw/usb/redirect.c) vdagent - doesn't have a dedicated channel so not really a problem.

Post by Charles.Tsai-蔡清海-研究發展部
I am thinking to remedy such a problem by sending a message to spice client thru the main channel. After spice client receives that message, it creates and initialize the "printing object". Although it is not good approach, it is the easy way to fix this issue for us. Let me know if you have a better idea. Thanks.

So I guess something like the following would be a better solution:

diff --git a/spice-qemu-char.c b/spice-qemu-char.c index 1e735ff..d3ae0b7 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -226,12 +226,14 @@ CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
chr->chr_guest_open = spice_chr_guest_open;
chr->chr_guest_close = spice_chr_guest_close;

-#if SPICE_SERVER_VERSION < 0x000901
- /* See comment in vmc_state() */
if (strcmp(subtype, "vdagent") == 0) {
+#if SPICE_SERVER_VERSION < 0x000901
+ /* See comment in vmc_state() */
qemu_chr_generic_open(chr);
- }
#endif
+ } else {
+ vmc_register_interface(s);
+ }

return chr;
}


Hans, any comments?

Post by Charles.Tsai-蔡清海-研究發展部
======================================================================
============================================================
Starting QEMU with...
-localtime -drive file=/var/lib/libvirt/images/Windows-7-32.img -vga
qxl -spice port=5900,disable-ticketing -device virtio-serial-pci,ioeventfd=off -chardev spicevmc,id=vdagent,name=vdagent,debug=2 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdprint,name=vdprint,debug=2 -device virtserialport,chardev=vdprint,name=com.redhat.print.0 -smp 1,cores=2 -m 2048 -enable-kvm ....
do_spice_init: starting 0.10.1
spice_server_add_interface: spice_server_add_interface: type=migration
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: spice_server_add_interface: type=keyboard
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: spice_server_add_interface: type=mouse
spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: spice_server_add_interface: type=qxl
spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
display_channel_create: create display channel
cursor_channel_create: create cursor channel
scd: 1: vmc_register_interface
type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdagent
scd: 2: vmc_register_interface
type=char_device
spice_server_char_device_add_interface: CHAR_DEVICE vdprint
spice_server_char_device_add_interface: Connect SPICE_CHANNEL_PRINT
spice_chr_write
scd: 1: spice_chr_write: 36
scd: 1: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 2: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 3: vmc_read: vdagent (nil) 8/0/0
scd: 4: vmc_read: vdagent (nil) 8/0/0
spice_chr_write
scd: 2: spice_chr_write: 36
scd: 5: vmc_read: vdagent 0x7f7ff3f98c80 8/8/36
scd: 6: vmc_read: vdagent 0x7f7ff3f98c88 28/28/28
scd: 7: vmc_read: vdagent (nil) 8/0/0
scd: 8: vmc_read: vdagent (nil) 8/0/0
-----Original Message-----
Sent: Tuesday, April 03, 2012 3:54 PM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
In spice client, the creation of the channel is based on "init->num_of_channels" that is returned from the spice server.
Please see the following function to create the spice channel from the client
void RedClient::handle_channels(RedPeer::InMessage* message) {
SpiceMsgChannels *init = (SpiceMsgChannels *)message->data();
SpiceChannelId* channels = init->channels;
for (unsigned int i = 0; i < init->num_of_channels; i++) {
create_channel(channels[i].type, channels[i].id);
}
}
For the printing channel, it is created and registered by function
spicevmc_device_connect(char_device, SPICE_CHANNEL_PRINT); (see in reds.c file) Because the printing channel is registered and created in spice server lately after spice client is up, the creation of the printing channel is thus skipped by the spice client.

Two things: First, you are using the old client code base as an example.
All well and good, but if possible it's better to use spice-gtk as a base for new features, because that's the client we are going with forwward (or actually the client enabling library, with remote-viewer being the preffered client).
Second, what do you mean registered after the spice client is up? If
there is some race window where the server is already listening to
clients but the printing channel is not registered, that is bad and
needs fixing, but in general the server is initialized *before* the
client is connected. The right order is 1. server channels are
registered 2. server starts listening 3. client connects
#3 cannot come before #2 so in general there is no way to have the situation you describe (unless there is a race and #1 happens after #2 and then both orders with respect to #3 are possible).

Post by Charles.Tsai-蔡清海-研究發展部
Can you tell me how to resolve this problem based on the spice architecture? Thanks.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, March 30, 2012 9:27 AM
To: 'Alon Levy'
Subject: RE: Read data out of the Virtqueue
Alon,
It is a bug that I modified for printing channel. BTW, can a spice channel be brought up or down based on a request from a spice client?
The reason that I am asking for such a question is because the printing channel might be brought up based on a configuration policy. I would like to know if a spice channel can be brought up dynamically during the run time.
-----Original Message-----
Sent: Friday, March 30, 2012 4:16 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: Read data out of the Virtqueue

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Forget my previous mail. When I dig into the vdservice, I found there was one bug to check the overlay I/O status after calling the VirtIO write function.
After I fixed the bug, I can see more printing raw data inside the Qemu now. Although I still find some issues, hopefully I can fix it as I debug more codes in both spice client and spice server. Thank you for your time.

Great that you managed to progress. Can you send a patch for the vdservice issue? Is it a bug in the original or just in the one you modified for printer channel?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Wednesday, March 28, 2012 6:07 PM
To: 'Alon Levy'
Subject: Read data out of the Virtqueue
Alon,
My printer driver can write the printing raw data into virtIO driver. But I cannot see the found the printing raw data in the spice server. For the vdagent, I found the following code segment which is a callback to read the data from the vdi_port. Do I need to add a similar code to read the data from the Virtio?
In Qemu, I do see vmc_write is called when the printer driver writes the printing raw data into the virtIOdevice.
Consequently, function "spicevmc_red_channel_send_item" should be called to send the payload to the spice client. But I did not see function "spicevmc_red_channel_send_item" is called either. It looks like the printing rawa data is still inside the VirtIO queue. What function I need to add so as to pull the data out of the VirtIO queue?
==================================================================
== == ================= struct SpiceCharDeviceState
vdagent_char_device_state = {
.wakeup = &vdagent_char_device_wakeup, };
void vdagent_char_device_wakeup(SpiceCharDeviceInstance *sin) {

[Alon Levy]

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
Do you recommend us to use the new spice client code from "http://www.spice-space.org/downloads.html" link?
I will try to use it latter on to see what it is difference.
You are right. The printing channel is created when the guest OS opens the virtIO printing channel. That is why it happens so lately.

OK, we agree.

[Yonit Halperin]

Hi,

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I read the spice code and found a spice tunnel channel there. What is the purpose of the tunnel channel? Is it for network tunneling?
What is the use case for tunnel channel in spice?

The tunnel was intended for redirecting a virtual network in the guest
to the client. Its main use was for network printer redirection.
The idea was to have a dedicated nic in the guest whose packets where
handled by a library based on slirp (it is still downloadable from
spice-space.org). Instead of using BSD sockets, you could register
other socket callbacks to this library, e.g., callbacks in the tunnel
worker. These callbacks forwarded the connections meta data and the
application layer of the packets to the client.

Regards,
Yonit.

Post by Charles.Tsai-蔡清海-研究發展部
_______________________________________________
Spice-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Charles.Tsai-蔡清海-研究發展部]

Hi Yonit,

I am currently implementing a printing redirect based on the Virio framework. Can I use tunnel channel to forward printing file from the guest OS to the client?
If I can do it, is there any API that I can call from the guest OS to inject the printing data into the tunnel channel?

Right now, I am debugging the printing channel based on the VirtIO framework and I found the VirtIO is extremely unstable. Sometimes, it works and sometimes it fails.
VirtIO is fairly buggy. Is tunnel channel being used or is it a just a experiment(proof of concept)?




-----Original Message-----
From: Yonit Halperin [mailto:***@redhat.com]
Sent: Monday, March 26, 2012 3:32 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Alon Levy; spice-***@lists.freedesktop.org
Subject: Re: [Spice-devel] SPICE_CHANNEL_TUNNEL

Hi,

Post by Charles.Tsai-蔡清海-研究發展部
Alon,
I read the spice code and found a spice tunnel channel there. What is the purpose of the tunnel channel? Is it for network tunneling?
What is the use case for tunnel channel in spice?

The tunnel was intended for redirecting a virtual network in the guest to the client. Its main use was for network printer redirection.
The idea was to have a dedicated nic in the guest whose packets where handled by a library based on slirp (it is still downloadable from spice-space.org). Instead of using BSD sockets, you could register other socket callbacks to this library, e.g., callbacks in the tunnel worker. These callbacks forwarded the connections meta data and the application layer of the packets to the client.

Regards,
Yonit.

Post by Charles.Tsai-蔡清海-研究發展部
_______________________________________________
Spice-devel mailing list
http://lists.freedesktop.org/mailman/l

[Vadim Rozenfeld]

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS
on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest
OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Vadim Rozenfeld]

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes
have been merged already by Yan into this
public repository.
I will ask to update binaries and sources at
fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS
on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest
OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

Thanks. We will download the code from Yan's repository.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver? From my test, the latest code from (https://github.com/YanVugenfirer/) seemed to be worst than the one we tested before. Let me know if we did anything wrong.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver? From my test, the latest code from (https://github.com/YanVugenfirer/) seemed to be worst than the one we tested before. Let me know if we did anything wrong.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Vadim Rozenfeld]

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver?

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver? From my test, the latest code from (https://github.com/YanVugenfirer/) seemed to be worst than the one we tested before. Let me know if we did anything wrong.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.

[Vadim Rozenfeld]

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git
,and
qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as
compiled by myself with the sources from our internal repository
(which contains absolutely the same code as in Yan's repository).



----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver?

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked.
The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.

As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is much more stable than the old one. But those drivers must work with Qemu 1.0.50 which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a recommendation.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with the sources from our internal repository (which contains absolutely the same code as in Yan's repository).



----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver? From my test, the latest code from (https://github.com/YanVugenfirer/) seemed to be worst than the one we tested before. Let me know if we did anything wrong.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up wi

[Vadim Rozenfeld]

I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.

Maybe someone from the SPICE team can comment on your question?

Best regards,
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Wednesday, February 8, 2012 4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked.
The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.

As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is much more stable than the old one. But those drivers must work with Qemu 1.0.50 which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a recommendation.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with the sources from our internal repository (which contains absolutely the same code as in Yan's repository).



----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver?

[David Jaša]

Post by Vadim Rozenfeld
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?

We also focus our testing on RHEL components. We have done some new
feature testing on Fedora with virt-preview repo:
http://repos.fedorapeople.org/repos/jforbes/virt-preview/
but it still says nothing about qemu stability for your purposes and the
qemu version is still 1.0.

David

Post by Vadim Rozenfeld
Best regards,
Vadim.
----- Original Message -----
Sent: Wednesday, February 8, 2012 4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked.
The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is much more stable than the old one. But those drivers must work with Qemu 1.0.50 which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with the sources from our internal repository (which contains absolutely the same code as in Yan's repository).
----- Original Message -----
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver?

[Charles.Tsai-蔡清海-研究發展部]

Hi Vadim,

We recently encountered with many issues with new Windows Virio driver running on Qemu 1.0 and Qemu 1.0.50.
My initial investigation was found that the new Viro driver could not be installed before Qemu 1.0.50.
But my colleague right now can install the new Virio driver on Qemu 1.0. Such a finding is quite a bit surprise to me.

When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we found the Virio driver failed to work after disabling and enabling the driver a few times.
However, the failure case largely depends on the type of machine. On my machine, I did not see such a problem.

Here are a few of questions that I want to clarify for us.

1. Can the new VirIO driver be installed prior Qemu 1.0.50(the current head branch)?
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50? Do you recommend us to do such a test or debugging?

3. When we disable and enable the new VirtIO driver several times on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after enabling the new VirtIO driver.
What we found in this particular case is that the VirtIO driver was blocked inside the DPC routine where the driver tried to ACK the interrupt. Based on my colleague's observation, the I/O read from DPC was not trapped by the front-end driver(a Linux driver implemented for VirtIO)? Do you have any idea why this could happen? Also, did you find similar issues by you or your QA?

Please let us know these as soon as possible since we have a big trouble to make the Virio driver(new and old driver) work stably in any Qemu official release
including Qemu 1.0.50.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL process on RHEL platform only.

Maybe someone from the SPICE team can comment on your question?

Best regards,
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Wednesday, February 8, 2012 4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked.
The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.

As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is much more stable than the old one. But those drivers must work with Qemu 1.0.50 which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a recommendation.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 -drive file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with the sources from our internal repository (which contains absolutely the same code as in Yan's repository).



----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>, "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>, "Paul Lu-盧偉智-研究發展部" <***@cloudena.com>
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the same. In other words, the latest driver source from https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

I downloaded the latest Windows guest driver code from (https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the driver seemed to wait for something to happen and the update driver Windows dialog simply just stayed in busy state. Finally, the Windows system entered a busy loop. However, if I tested the debugging build driver, the driver could be installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can verify the vioserial driver? From my test, the latest code from (https://github.com/YanVugenfirer/) seemed to be worst than the one we tested before. Let me know if we did anything wrong.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

----- Original Message -----
From: "Charles.Tsai-蔡清海-研究發展部" <***@cloudena.com>
To: "Vadim Rozenfeld" <***@redhat.com>
Cc: "Michael Roth" <***@linux.vnet.ibm.com>, "Stefan Hajnoczi" <***@gmail.com>, spice-***@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" <***@cloudena.com>, "Alon Levy" <***@redhat.com>, "qemu-devel" <qemu-***@nongnu.org>
Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same binary to test Qemu.


-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had problem to install on 64-bit Win7 guest.
During the driver installation, the system hung after the driver
being installed. After I rebooted the guest OS, the Vioserial driver work. The hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O address of the vioserial device and map the physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to be broken in vioserial device.
Let me know if you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If so
I'll see if the issues go away on 0.14.0 and follow-up with a g

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio driver
running on Qemu 1.0 and Qemu 1.0.50. My initial investigation was found
that the new Viro driver could not be installed before Qemu 1.0.50. But
my colleague right now can install the new Virio driver on Qemu 1.0. Such
a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we found
the Virio driver failed to work after disabling and enabling the driver a
few times. However, the failure case largely depends on the type of
machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu
1.0.50? Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular case is
that the VirtIO driver was blocked inside the DPC routine where the driver
tried to ACK the interrupt. Based on my colleague's observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux driver
implemented for VirtIO)? Do you have any idea why this could happen? Also,
did you find similar issues by you or your QA?

I know for sure that we have at least one race condition described here:
https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big trouble
to make the Virio driver(new and old driver) work stably in any Qemu
official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.

Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50
from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked. The
latest Windows guest driver from (https://github.com/YanVugenfirer/) seems
to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and
that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old one.
But those drivers must work with Qemu 1.0.50 which was not verified to be
stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a
recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50
from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,forma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
-cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself
with the sources from our internal repository (which contains absolutely
the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom was the
same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the
driver seemed to wait for something to happen and the update driver
Windows dialog simply just stayed in busy state. Finally, the Windows
system entered a busy loop. However, if I tested the debugging build
driver, the driver could be installed. But it took for a long time to
complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that we can
verify the vioserial driver?

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

What do you mean "qemu configuration string"? Is it the build configuration or command line option?
Please let me know it. Thanks.




-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before Qemu
1.0.50. But my colleague right now can install the new Virio driver on
Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling the
driver a few times. However, the failure case largely depends on the
type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular case
is that the VirtIO driver was blocked inside the DPC routine where the driver
tried to ACK the interrupt. Based on my colleague's observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could happen? Also,
did you find similar issues by you or your QA?

I know for sure that we have at least one race condition described here:
https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu configuration string and I'll try to reproduce it and investigate this problem.

Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it
worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old one.
But those drivers must work with Qemu 1.0.50 which was not verified to
be stable. Do you think Qemu 1.0.50 is stable to be used? Please give
us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifun
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
-cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7,
the driver seemed to wait for something to happen and the update
driver Windows dialog simply just stayed in busy state. Finally, the
Windows system entered a busy loop. However, if I tested the debugging
build driver, the driver could be installed. But it took for a long
time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that we
can verify the vioserial driver? From my test, the latest code from
(https://github.com/YanVugenfirer/) seemed to be worst than the one we
tested before. Let me know if we did anything wrong.
-----Original Message-----
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: Re: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by
Yan into this public repository. I will ask to update binaries and
sources at fedoraproject site as well.
Best regards,
Vadim.
----- Original Message -----
January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/vir
tio-
win-prewhql-0.1-15-sources.zip
-----Original Message-----
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: Re: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?
----- Original Message -----
Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We built it from the driver source. Up to this moment, we always use
the same binary to test Qemu.
-----Original Message-----
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: RE: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had
problem to install on 64-bit Win7 guest. During the driver
installation, the system hung after the driver being installed.
After I rebooted the guest OS, the Vioserial driver work. The hang
system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information for
our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monito
r,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on
,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,fo
rm
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bo
ot
in
de
x=1
-netdev tap,fd=17,id=hostnet0
-device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.
0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,
id
=c
ha
nnel0,name=com.redhat.spice.0
-usb -device usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr
=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device
is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to get
the I/O address of the vioserial device and map the physical
address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu
0.15 seemed to be broken in vioserial device. Let me know if
you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3
works intermittently for me using RHEL6.0 virtio-win, as well as
the

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bi
n/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally
resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing? If
so I'll see if the issues go away on 0.14.0

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
What do you mean "qemu configuration string"? Is it the build configuration
or command line option? Please let me know it. Thanks.

Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.

Cheers,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before Qemu
1.0.50. But my colleague right now can install the new Virio driver on
Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling the
driver a few times. However, the failure case largely depends on the
type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what is
the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular case
is that the VirtIO driver was blocked inside the DPC routine where the
driver tried to ACK the interrupt. Based on my colleague's
observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could
happen? Also, did you find similar issues by you or your QA?

https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.
Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it
worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old one.
But those drivers must work with Qemu 1.0.50 which was not verified to
be stable. Do you think Qemu 1.0.50 is stable to be used? Please give
us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifun
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chann
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
-cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver
code. When I tested the release build Vioserial driver on 64-bit Windows
7, the driver seemed to wait for something to happen and the update
driver Windows dialog simply just stayed in busy state. Finally, the
Windows system entered a busy loop. However, if I tested the debugging
build driver, the driver could be installed. But it took for a long time
to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that we
can verify the vioserial driver?

[Charles.Tsai-蔡清海-研究發展部]

Vadim,

My colleague will give you more information we found here.
Qemu somehow in this particular case returns a wrong bar0 value.
In working case, the bar0 is 0xc140. But in failure case, the bar0 is changed to 0xC141.



-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Monday, March 19, 2012 8:03 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
What do you mean "qemu configuration string"? Is it the build
configuration or command line option? Please let me know it. Thanks.

Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.

Cheers,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-蔡清海-研究發展部
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before
Qemu 1.0.50. But my colleague right now can install the new Virio
driver on Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling
the driver a few times. However, the failure case largely depends on
the type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular
case is that the VirtIO driver was blocked inside the DPC routine where the
driver tried to ACK the interrupt. Based on my colleague's
observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could
happen? Also, did you find similar issues by you or your QA?

https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.
Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing
WHQL process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and
it worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old one.
But those drivers must work with Qemu 1.0.50 which was not verified
to be stable. Do you think Qemu 1.0.50 is stable to be used? Please
give us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0
,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multif
un
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nn
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot
-enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver
code. When I tested the release build Vioserial driver on 64-bit
Windows 7, the driver seemed to wait for something to happen and the
update driver Windows dialog simply just stayed in busy state.
Finally, the Windows system entered a busy loop. However, if I
tested the debugging build driver, the driver could be installed.
But it took for a long time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that
we can verify the vioserial driver? From my test, the latest code
from
(https://github.com/YanVugenfirer/) seemed to be worst than the one
we tested before. Let me know if we did anything wrong.
-----Original Message-----
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: Re: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by
Yan into this public repository. I will ask to update binaries and
sources at fedoraproject site as well.
Best regards,
Vadim.
----- Original Message -----
Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We downloaded the driver source from the following website.
===========================================================
wget --no-check-certificate
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/v
ir
tio-
win-prewhql-0.1-15-sources.zip
-----Original Message-----
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: Re: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?
----- Original Message -----
Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We built it from the driver source. Up to this moment, we always use
the same binary to test Qemu.
-----Original Message-----
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel Subject: RE: [Qemu-devel]
[Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
It is SMP system.

What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Thursday, January 19, 2012 3:58 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi;
Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
I tested on Qemu 1.0.50. and found the VioSerial driver had
problem to install on 64-bit Win7 guest. During the driver
installation, the system hung after the driver being installed.
After I rebooted the guest OS, the Vioserial driver work. The
hang system seemed to be found only during the driver installation.

On UP or SMP system?

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, January 18, 2012 4:57 AM
To: Michael Roth
Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows
guest OS on Qemu 0.15

Post by Vadim Rozenfeld

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
Thank you for your prompt reply. Here are the information
for our test case.
1) we use the following command line to launch the guest OS
/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name win_xp -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig
-nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.moni
to
r,
se rv er,nowait -mon
chardev=charmonitor,id=monitor,mode=readline
-rtc base=localtime
-device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=
on
,a
dd
r=
0x5.0x0 -drive
file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,
fo
rm
at
=r
aw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,
bo
ot
in
de
x=1
-netdev tap,fd=17,id=hostnet0 -device
rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.
0,
mu
lt
ifunction=on,addr=0x3.0x0
-chardev pty,id=charserial0
-device isa-serial,chardev=charserial0,id=serial0
-chardev spicevmc,id=charchannel0,name=vdagent
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel
0,
id
=c
ha
nnel0,name=com.redhat.spice.0 -usb -device
usb-tablet,id=input0 -spice
port=5900,addr=0.0.0.0,disable-ticketing
-vga qxl -global qxl-vga.vram_size=67108864 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,ad
dr
=0
x4
.0
x0
2). In Guest Windows XP OS
When the following callback function of the vioserial device
is called in guest OS. The allocated resources is empty.
VIOSerialEvtDevicePrepareHardware() ---This function is to
get the I/O address of the vioserial device and map the
physical address to the logical address space.
I added the following trace and the value of nListSize is ZERO.
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s
(nListSize=%d)\n", __FUNCTION__,nListSize);
So far, we have tested Qemu 0.14 without any problem but Qemu
0.15 seemed to be broken in vioserial device. Let me know if
you need further information. Thanks.

Hi Charles,
What versions of the virtio-win drivers are you using?
I've been testing virtio-serial on windows using the latest
qemu.git (1.0). Linux guests work fine, but I've been having
various issues with Windows 7, XP SP3, and Server 2008 R1. XP SP3
works intermittently for me using RHEL6.0 virtio-win, as well
as the

I have seen some virtio serial port initialization problems on
1.0.50. Will try to look into this problem in the following week(s).

Post by Vadim Rozenfeld
http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/
bi
n/
But I've been getting a mix of issues such as guest hangs,
vioser-test failing to enumerate any virtio-serial devices, or
various non-critical error messages from qemu that seem to
coincide with the channel being open/closed (occasionally
resulting in the channel becoming unresponsive).
Do any of these seem similar to the behaviour you're seeing?
If so I'll see if the issues go away on 0.14.0 and follow-up

[Paul Lu-???-?????]

Hi Vadim,
Here is the configuration:
/usr/local/bin/qemu-system-x86_64 \
-localtime \
-boot order=c,menu=on \
-drive file=/var/lib/libvirt/images/xxx.img \
-vga qxl \
-cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
-chardev spicevmc,id=vdagent,name=vdagent \
-spice port=5930,disable-ticketing \
-device virtio-serial-pci \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-smp 1,cores=1 -m 2048 \
-enable-kvm \
-usbdevice tablet \
-net nic -net user \
-tb-size 0 \
-qmp tcp:localhost:4444,nowait,server \
-D /home/paul/MyQemuLog/xxx/xxx.log \
-trace events=/home/paul/MyTestCase/xxx/events

QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8


I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows 0xC140.
However, pci_default_read_config in pci.c return 0xC141 to Guest.
We also trace pci_default_wirte_config.

At some point, the BAR0 will be overwritten to 0xC141. Here is the result,

virtio_set_status vdev 0x7fbeaba594a0 val 0
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:1,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:1, len=4
qemu-system-x86_64: [WRITE]10:c140, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:c141, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4

I think the following code in pci_default_wirte_config cause the problem,
for (i = 0; i < l; val >>= 8, ++i) {
uint8_t wmask = d->wmask[addr + i];
uint8_t w1cmask = d->w1cmask[addr + i];
assert(!(wmask & w1cmask));
d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val & wmask);
d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear */
}

Could you elaborate it for us?


Best Regards,
Paul

-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Mon 3/19/2012 8:32 PM
To: Vadim Rozenfeld
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-???-?????; Alon Levy; qemu-devel; Paul Lu-???-?????
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Vadim,

My colleague will give you more information we found here.
Qemu somehow in this particular case returns a wrong bar0 value.
In working case, the bar0 is 0xc140. But in failure case, the bar0 is changed to 0xC141.



-----Original Message-----
From: Vadim Rozenfeld [mailto:***@redhat.com]
Sent: Monday, March 19, 2012 8:03 PM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi; spice-***@lists.freedesktop.org; Alex Huang-???-?????; Alon Levy; qemu-devel; Paul Lu-???-?????
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
What do you mean "qemu configuration string"? Is it the build
configuration or command line option? Please let me know it. Thanks.

Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.

Cheers,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-???-?????
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before
Qemu 1.0.50. But my colleague right now can install the new Virio
driver on Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling
the driver a few times. However, the failure case largely depends on
the type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular
case is that the VirtIO driver was blocked inside the DPC routine where the
driver tried to ACK the interrupt. Based on my colleague's
observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could
happen? Also, did you find similar issues by you or your QA?

https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.
Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing
WHQL process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
2012
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and
it worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old one.
But those drivers must work with Qemu 1.0.50 which was not verified
to be stable. Do you think Qemu 1.0.50 is stable to be used? Please
give us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0
,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multif
un
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nn
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot
-enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
2012
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver
code. When I tested the release build Vioserial driver on 64-bit
Windows 7, the driver seemed to wait for something to happen and the
update driver Windows dialog simply just stayed in busy state.
Finally, the Windows system entered a busy loop. However, if I
tested the debugging build driver, the driver could be installed.
But it took for a long time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
/usr/local/bin/qemu-system-x86_64 \
-localtime \
-boot order=c,menu=on \
-drive file=/var/lib/libvirt/images/xxx.img \
-vga qxl \
-cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
-chardev spicevmc,id=vdagent,name=vdagent \
-spice port=5930,disable-ticketing \
-device virtio-serial-pci \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-smp 1,cores=1 -m 2048 \
-enable-kvm \
-usbdevice tablet \
-net nic -net user \
-tb-size 0 \
-qmp tcp:localhost:4444,nowait,server \
-D /home/paul/MyQemuLog/xxx/xxx.log \
-trace events=/home/paul/MyTestCase/xxx/events
QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
0xC140. However, pci_default_read_config in pci.c return 0xC141 to Guest.
We also trace pci_default_wirte_config.
At some point, the BAR0 will be overwritten to 0xC141. Here is the result,
virtio_set_status vdev 0x7fbeaba594a0 val 0
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:1,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:1, len=4
qemu-system-x86_64: [WRITE]10:c140, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:c141, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
I think the following code in pci_default_wirte_config cause the problem,
for (i = 0; i < l; val >>= 8, ++i) {
uint8_t wmask = d->wmask[addr + i];
uint8_t w1cmask = d->w1cmask[addr + i];
assert(!(wmask & w1cmask));
d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
*/ }
Could you elaborate it for us?

Hi Paul,
Give me a couple of days.
Best,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
Best Regards,
Paul
-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Mon 3/19/2012 8:32 PM
To: Vadim Rozenfeld
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
My colleague will give you more information we found here.
Qemu somehow in this particular case returns a wrong bar0 value.
In working case, the bar0 is 0xc140. But in failure case, the bar0 is changed to 0xC141.
-----Original Message-----
Sent: Monday, March 19, 2012 8:03 PM
To: Charles.Tsai-???-?????
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
What do you mean "qemu configuration string"? Is it the build
configuration or command line option? Please let me know it. Thanks.

Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.
Cheers,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-???-?????
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before
Qemu 1.0.50. But my colleague right now can install the new Virio
driver on Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling
the driver a few times. However, the failure case largely depends on
the type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular
case is that the VirtIO driver was blocked inside the DPC routine where
the driver tried to ACK the interrupt. Based on my colleague's
observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could
happen? Also, did you find similar issues by you or your QA?

https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.
Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing
WHQL process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
2012
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and
it worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old
one. But those drivers must work with Qemu 1.0.50 which was not
verified to be stable. Do you think Qemu 1.0.50 is stable to be used?
Please give us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0
,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multif
un
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nn
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot
-enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
2012
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver
code. When I tested the release build Vioserial driver on 64-bit
Windows 7, the driver seemed to wait for something to happen and the
update driver Windows dialog simply just stayed in busy state.
Finally, the Windows system entered a busy loop. However, if I
tested the debugging build driver, the driver could be installed.
But it took for a long time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that
we can verify the vioserial driver?

[Vadim Rozenfeld]

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
/usr/local/bin/qemu-system-x86_64 \
-localtime \
-boot order=c,menu=on \
-drive file=/var/lib/libvirt/images/xxx.img \
-vga qxl \
-cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
-chardev spicevmc,id=vdagent,name=vdagent \
-spice port=5930,disable-ticketing \
-device virtio-serial-pci \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-smp 1,cores=1 -m 2048 \
-enable-kvm \
-usbdevice tablet \
-net nic -net user \
-tb-size 0 \
-qmp tcp:localhost:4444,nowait,server \
-D /home/paul/MyQemuLog/xxx/xxx.log \
-trace events=/home/paul/MyTestCase/xxx/events
QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
0xC140. However, pci_default_read_config in pci.c return 0xC141 to Guest.
We also trace pci_default_wirte_config.
At some point, the BAR0 will be overwritten to 0xC141. Here is the result,
virtio_set_status vdev 0x7fbeaba594a0 val 0
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:1,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:1, len=4
qemu-system-x86_64: [WRITE]10:c140, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: [WRITE]10:ffffffff, len=4
qemu-system-x86_64: 10:ffffffe1,len=4
qemu-system-x86_64: [WRITE]10:c141, len=4
virtio_set_status vdev 0x7fbeaba594a0 val 0
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
qemu-system-x86_64: 10:c141,len=4
I think the following code in pci_default_wirte_config cause the problem,
for (i = 0; i < l; val >>= 8, ++i) {
uint8_t wmask = d->wmask[addr + i];
uint8_t w1cmask = d->w1cmask[addr + i];
assert(!(wmask & w1cmask));
d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
*/ }
Could you elaborate it for us?
Best Regards,
Paul

Hi Paul,

1 in the lowest bit means that that it is an I/O space BAR.

Regarding installation problem on UP VM, the following patch should
fix this problem.
diff --git a/vioserial/sys/Device.c b/vioserial/sys/Device.c
index ecf2433..4fe1e12 100644
--- a/vioserial/sys/Device.c
+++ b/vioserial/sys/Device.c
@@ -547,8 +547,6 @@ VIOSerialEvtDeviceD0Entry(
{
VIOSerialInitAllQueues(Device);
VIOSerialRenewAllPorts(Device);
- TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Setting
VIRTIO_CONFIG_S_DRIVER_OK flag\n");
- VirtIODeviceAddStatus(pContext->pIODevice,
VIRTIO_CONFIG_S_DRIVER_OK);
}

return STATUS_SUCCESS;
@@ -601,6 +599,8 @@ VIOSerialEvtDeviceD0EntryPostInterruptsEnabled(
}
else if (PreviousState == WdfPowerDeviceD3Final)
{
+ TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Setting
VIRTIO_CONFIG_S_DRIVER_OK flag\n");
+ VirtIODeviceAddStatus(pContext->pIODevice,
VIRTIO_CONFIG_S_DRIVER_OK);
TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Sending
VIRTIO_CONSOLE_DEVICE_READY 1\n");
VIOSerialSendCtrlMsg(WdfDevice, VIRTIO_CONSOLE_BAD_ID,
VIRTIO_CONSOLE_DEVICE_READY, 1);
}


Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Mon 3/19/2012 8:32 PM
To: Vadim Rozenfeld
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
My colleague will give you more information we found here.
Qemu somehow in this particular case returns a wrong bar0 value.
In working case, the bar0 is 0xc140. But in failure case, the bar0 is changed to 0xC141.
-----Original Message-----
Sent: Monday, March 19, 2012 8:03 PM
To: Charles.Tsai-???-?????
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Vadim,
What do you mean "qemu configuration string"? Is it the build
configuration or command line option? Please let me know it. Thanks.

Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.
Cheers,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Monday, March 19, 2012 5:17 PM
To: Charles.Tsai-???-?????
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

Post by Charles.Tsai-蔡清海-研究發展部
Hi Vadim,
We recently encountered with many issues with new Windows Virio
driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
was found that the new Viro driver could not be installed before
Qemu 1.0.50. But my colleague right now can install the new Virio
driver on Qemu 1.0. Such a finding is quite a bit surprise to me.

Does Windows refuse to install a new driver or just stuck?

Post by Charles.Tsai-蔡清海-研究發展部
When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
found the Virio driver failed to work after disabling and enabling
the driver a few times. However, the failure case largely depends on
the type of machine. On my machine, I did not see such a problem.

Are you running SMP or UP guest? What about others?

Post by Charles.Tsai-蔡清海-研究發展部
Here are a few of questions that I want to clarify for us.
1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
current head branch)?

Yes, as far as I know.

Post by Charles.Tsai-蔡清海-研究發展部
2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
Do you recommend us to do such a test or debugging?

Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on
either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
enabling the new VirtIO driver. What we found in this particular
case is that the VirtIO driver was blocked inside the DPC routine where
the driver tried to ACK the interrupt. Based on my colleague's
observation,

the

Post by Charles.Tsai-蔡清海-研究發展部
I/O read from DPC was not trapped by the front-end driver(a Linux
driver implemented for VirtIO)? Do you have any idea why this could
happen? Also, did you find similar issues by you or your QA?

https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP?

Post by Charles.Tsai-蔡清海-研究發展部
Please let us know these as soon as possible since we have a big
trouble to make the Virio driver(new and old driver) work stably in
any Qemu official release including Qemu 1.0.50.

I'm going to push some changes, mostly related to the above bug.
The DPC problem is completely new for me. Please post your qemu
configuration string and I'll try to reproduce it and investigate this problem.
Best regards,
Vadim.

Post by Charles.Tsai-蔡清海-研究發展部
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:47 PM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing
WHQL process on RHEL platform only.
Maybe someone from the SPICE team can comment on your question?
Best regards,
Vadim.
----- Original Message -----
2012
4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
Thanks. I tested Windows guest OS driver the over qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and
it worked. The latest Windows guest driver from
(https://github.com/YanVugenfirer/) seems to have to work with Qemu
1.0.50. My previous test ran over Qemu 1.0 and that was why it failed to work.
As you mentioned, the latest driver from
(https://github.com/YanVugenfirer/) is much more stable than the old
one. But those drivers must work with Qemu 1.0.50 which was not
verified to be stable. Do you think Qemu 1.0.50 is stable to be used?
Please give us a recommendation.
-----Original Message-----
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
I have tried to reproduce the problem several times without success.
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel
1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
OS Name: Microsoft Windows 7 Enterprise
OS Version: 6.1.7600 N/A Build 7600
sudo
/home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc
base=localtime -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
0x
5.0x
0 -drive
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0
,f
orma
t=qcow2 -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
x=
1
-netdev tap,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multif
un
ctio
n=on,addr=0x3.0x0 -chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
spicevmc,id=charchannel0,name=vdagent -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
nn
el0,
name=com.redhat.spice.0 -usb -device usb-tablet,id=input0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
x0 -cdrom /home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot
-enable-kvm
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by
myself with the sources from our internal repository (which contains
absolutely the same code as in Yan's repository).
----- Original Message -----
3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the test.
-----Original Message-----
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-???-?????
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Thanks,
I'll check this problem.
Vadim.
----- Original Message -----
2012
5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
We tested the free build driver on 32-bit Windows 7 and the symptom
was the same. In other words, the latest driver source from
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.
-----Original Message-----
From: Charles.Tsai-???-?????
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi;
Alex
[Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Vadim,
I downloaded the latest Windows guest driver code from
(https://github.com/YanVugenfirer/) and built the test binary driver
code. When I tested the release build Vioserial driver on 64-bit
Windows 7, the driver seemed to wait for something to happen and the
update driver Windows dialog simply just stayed in busy state.
Finally, the Windows system entered a busy loop. However, if I
tested the debugging build driver, the driver could be installed.
But it took for a long time to complete.
Our installed Qemu is 1.0. Is there Qemu build requirement so that
we can verify the vioserial driver?

[Christophe Fergeau]

Hey,

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
after enabling the new VirtIO driver.

For what it's worth, Alon Levy also hit this particular bug a few months
ago, and I successfully reproduced at that time. I think I reported it to
Vadim back in the days, but I'm not 100% sure :)

Christophe

[Charles.Tsai-蔡清海-研究發展部]

Christophe,

Great!, we finally are at the same page.


-----Original Message-----
From: Christophe Fergeau [mailto:***@redhat.com]
Sent: Monday, March 19, 2012 6:13 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Vadim Rozenfeld; qemu-devel; Michael Roth; Paul Lu-盧偉智-研究發展部; spice-***@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部
Subject: Re: [Spice-devel] [Qemu-devel] Vioserial of Windows guest OS on Qemu 0.15

Hey,

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
after enabling the new VirtIO driver.

For what it's worth, Alon Levy also hit this particular bug a few months ago, and I successfully reproduced at that time. I think I reported it to Vadim back in the

[Vadim Rozenfeld]

Post by Christophe Fergeau
Hey,

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
after enabling the new VirtIO driver.

For what it's worth, Alon Levy also hit this particular bug a few months
ago, and I successfully reproduced at that time. I think I reported it to
Vadim back in the days, but I'm not 100% sure :)
Christophe

Thanks Christophe.
In your case (https://bugzilla.redhat.com/show_bug.cgi?id=750773)
an UP system hangs on shutdown.
I'm not sure whether Charles is hitting the same problem.

Best,
Vadim.

[Christophe Fergeau]

Post by Vadim Rozenfeld

Post by Christophe Fergeau
Hey,

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
after enabling the new VirtIO driver.

For what it's worth, Alon Levy also hit this particular bug a few months
ago, and I successfully reproduced at that time. I think I reported it to
Vadim back in the days, but I'm not 100% sure :)
Christophe

Thanks Christophe.
In your case (https://bugzilla.redhat.com/show_bug.cgi?id=750773)
an UP system hangs on shutdown.

In my case, the hang was during boot even though it magically went away
sometimes in the last month

Post by Vadim Rozenfeld
I'm not sure whether Charles is hitting the same problem.

While trying to figure out what was going on with the bug above, I've
definitely hit a "enabling/disabling vioserial in the device manager 3
times causes the VM to freeze" bug.
For what it's worth, lately I've also been experiencing VM freezes when
installing vioserial in winxp or win7 UP VMs

Christophe

[Vadim Rozenfeld]

Post by Christophe Fergeau

Post by Vadim Rozenfeld

Post by Christophe Fergeau
Hey,

Post by Charles.Tsai-蔡清海-研究發展部
3. When we disable and enable the new VirtIO driver several times
on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
after enabling the new VirtIO driver.

For what it's worth, Alon Levy also hit this particular bug a few
months ago, and I successfully reproduced at that time. I think I
reported it to Vadim back in the days, but I'm not 100% sure :)
Christophe

Thanks Christophe.
In your case (https://bugzilla.redhat.com/show_bug.cgi?id=750773)
an UP system hangs on shutdown.

In my case, the hang was during boot even though it magically went away
sometimes in the last month

Post by Vadim Rozenfeld
I'm not sure whether Charles is hitting the same problem.

While trying to figure out what was going on with the bug above, I've
definitely hit a "enabling/disabling vioserial in the device manager 3
times causes the VM to freeze" bug.
For what it's worth, lately I've also been experiencing VM freezes when
installing vioserial in winxp or win7 UP VMs

OK. It looks like the same race condition, which I'm going to fix.

Post by Christophe Fergeau
Christophe