Xen users - Jun 2012 - GPLPV, clock drift and PVUSB in Windows XP HVM

1. Shouldn''t the GPLPV drivers take care of the (bad) clock drift
I''m experiencing in my Windows XP HVM? Or is there some other way
around this problem that I haven''t been able to find on Google? How can
I tell if the GPLPV drivers are active? I''ve added the /gplpv switch to
the boot.ini file and the virtual NIC is definitely using the GPLPV version but
other than that I''m not sure how to tell.

The clock drift is too bad to be corrected by Windows'' built-in NTP
utility, and besides it needs to be corrected constantly, not every 2 weeks or
whatever. I''m using this particular VM as a scheduling agent that
performs tasks at certain times each day so it''s important for it to
have an accurate sense of time.

2. On this same Windows XP HVM, I''d like to experiment with the PVUSB
2.0 pass thru. My server (Dell PowerEdge 2900) does NOT support IOMMU so it
can''t be hardware. I''ve read that the PVUSB performance is up
to about 60% of native 2.0, but still better than the qemu 1.1 pass thru.
Unfortunately, I can''t find any documentation online about how to
actually use it. Currently I have these lines in my .cfg file:
usb = 1
usbdevice = ''tablet''
usbdevice = ''host:xxxx:yyyy''
Obviously I would need to remove the host: line to free up the device from qemu
pass thru so I can use PVUSB pass thru instead, but after that I''m not
sure what commands to issue or put in the domain''s .cfg file.
P.S. I did choose to install PvUsb when installing GPLPV so I''m
assuming that''s all I need to do on the domU end.

Thanks in advance for your help,
Eric Lindsey

> 
> 1. Shouldn''t the GPLPV drivers take care of the (bad) clock drift
I''m
> experiencing in my Windows XP HVM? Or is there some other way around
> this problem that I haven''t been able to find on Google? How can I
tell if the
> GPLPV drivers are active? I''ve added the /gplpv switch to the
boot.ini file and
> the virtual NIC is definitely using the GPLPV version but other than that
I''m
> not sure how to tell.
You don''t need to use any switches to make gplpv active. You can use
the /nogplpv switch to make it inactive if required for testing, but that only
deactivates the vbd and vif drivers.

GPLPV won''t (shouldn''t) have any impact on clock drift. If you
only get clock drift when running with GPLPV then let me know.
> 2. On this same Windows XP HVM, I''d like to experiment with the
PVUSB 2.0
> pass thru. My server (Dell PowerEdge 2900) does NOT support IOMMU so it
> can''t be hardware. I''ve read that the PVUSB performance
is up to about 60%
> of native 2.0, but still better than the qemu 1.1 pass thru. Unfortunately,
I
> can''t find any documentation online about how to actually use it.
Currently I
> have these lines in my .cfg file:
> usb = 1
> usbdevice = ''tablet''
> usbdevice = ''host:xxxx:yyyy''
> Obviously I would need to remove the host: line to free up the device from
> qemu pass thru so I can use PVUSB pass thru instead, but after that
I''m not
> sure what commands to issue or put in the domain''s .cfg file.
> P.S. I did choose to install PvUsb when installing GPLPV so I''m
assuming that''s
> all I need to do on the domU end.
> 
You need to make sure you have usb backend drivers in your dom0, then you use xm
to add host controllers and devices. Google for usb-hc-create and you should
find some info.

James

I''m sorry for being unclear in my original message. I''m
experiencing the clock drift with and without the GPLPV drivers. However, I was
surprised that those drivers didn''t include their own version of
Linux''s independent_wallclock, which I presume takes care of the clock
drift problem in those operating systems (though I''ll be the first to
admit that''s merely an assumption and I''ve very little
experience in this area). How can I solve the clock drift problem, and keep my
XP HVM synchronized with my dom0 hardware clock (which does not suffer from
drift)?

The info on the /nogplpv switch is useful; I''m surprised it
isn''t documented somewhere more obvious than what I could find with a
Google search.

Thanks for the reply, James! 

On Jun 29, 2012, at 3:18 AM, James Harper <james.harper@bendigoit.com.au>
wrote:
>> 
>> 1. Shouldn''t the GPLPV drivers take care of the (bad) clock
drift I''m
>> experiencing in my Windows XP HVM? Or is there some other way around
>> this problem that I haven''t been able to find on Google? How
can I tell if the
>> GPLPV drivers are active? I''ve added the /gplpv switch to the
boot.ini file and
>> the virtual NIC is definitely using the GPLPV version but other than
that I''m
>> not sure how to tell.
> 
> You don''t need to use any switches to make gplpv active. You can
use the /nogplpv switch to make it inactive if required for testing, but that
only deactivates the vbd and vif drivers.
> 
> GPLPV won''t (shouldn''t) have any impact on clock drift.
If you only get clock drift when running with GPLPV then let me know.
> 
>> 2. On this same Windows XP HVM, I''d like to experiment with
the PVUSB 2.0
>> pass thru. My server (Dell PowerEdge 2900) does NOT support IOMMU so it
>> can''t be hardware. I''ve read that the PVUSB
performance is up to about 60%
>> of native 2.0, but still better than the qemu 1.1 pass thru.
Unfortunately, I
>> can''t find any documentation online about how to actually use
it. Currently I
>> have these lines in my .cfg file:
>> usb = 1
>> usbdevice = ''tablet''
>> usbdevice = ''host:xxxx:yyyy''
>> Obviously I would need to remove the host: line to free up the device
from
>> qemu pass thru so I can use PVUSB pass thru instead, but after that
I''m not
>> sure what commands to issue or put in the domain''s .cfg file.
>> P.S. I did choose to install PvUsb when installing GPLPV so
I''m assuming that''s
>> all I need to do on the domU end.
>> 
> 
> You need to make sure you have usb backend drivers in your dom0, then you
use xm to add host controllers and devices. Google for usb-hc-create and you
should find some info.
> 
> James

On Fri, Jun 29, 2012 at 3:45 AM, Eric Lindsey <eslindsey@gmail.com>
wrote:
> I''m sorry for being unclear in my original message. I''m
experiencing the clock drift with and without the GPLPV drivers. However, I was
surprised that those drivers didn''t include their own version of
Linux''s independent_wallclock, which I presume takes care of the clock
drift problem in those operating systems (though I''ll be the first to
admit that''s merely an assumption and I''ve very little
experience in this area). How can I solve the clock drift problem, and keep my
XP HVM synchronized with my dom0 hardware clock (which does not suffer from
drift)?
>
> The info on the /nogplpv switch is useful; I''m surprised it
isn''t documented somewhere more obvious than what I could find with a
Google search.
>
> Thanks for the reply, James!
>
> On Jun 29, 2012, at 3:18 AM, James Harper
<james.harper@bendigoit.com.au> wrote:
>
>>>
>>> 1. Shouldn''t the GPLPV drivers take care of the (bad)
clock drift I''m
>>> experiencing in my Windows XP HVM? Or is there some other way
around
>>> this problem that I haven''t been able to find on Google?
How can I tell if the
>>> GPLPV drivers are active? I''ve added the /gplpv switch to
the boot.ini file and
>>> the virtual NIC is definitely using the GPLPV version but other
than that I''m
>>> not sure how to tell.
>>
>> You don''t need to use any switches to make gplpv active. You
can use the /nogplpv switch to make it inactive if required for testing, but
that only deactivates the vbd and vif drivers.
>>
>> GPLPV won''t (shouldn''t) have any impact on clock
drift. If you only get clock drift when running with GPLPV then let me know.
>>
>>> 2. On this same Windows XP HVM, I''d like to experiment
with the PVUSB 2.0
>>> pass thru. My server (Dell PowerEdge 2900) does NOT support IOMMU
so it
>>> can''t be hardware. I''ve read that the PVUSB
performance is up to about 60%
>>> of native 2.0, but still better than the qemu 1.1 pass thru.
Unfortunately, I
>>> can''t find any documentation online about how to actually
use it. Currently I
>>> have these lines in my .cfg file:
>>> usb = 1
>>> usbdevice = ''tablet''
>>> usbdevice = ''host:xxxx:yyyy''
>>> Obviously I would need to remove the host: line to free up the
device from
>>> qemu pass thru so I can use PVUSB pass thru instead, but after that
I''m not
>>> sure what commands to issue or put in the domain''s .cfg
file.
>>> P.S. I did choose to install PvUsb when installing GPLPV so
I''m assuming that''s
>>> all I need to do on the domU end.
>>>
>>
>> You need to make sure you have usb backend drivers in your dom0, then
you use xm to add host controllers and devices. Google for usb-hc-create and you
should find some info.
>>
>> James
I did what you suggested and found a lot of the information I needed.
I successfully created a host controller using
root@www:~# xm usb-hc-create LightJockey 2 4
and the Add New Hardware wizard immediately showed up in my HVM.  I
successfully installed the drivers there (which I believe to be
usbfront drivers from GPLPV).  But now here''s my current problem:

root@www:~# xm usb-list-assignable-devices
1-7.1        : ID 413c:2105 Dell Dell USB Keyboard
3-1          : ID 0962:1000 DigitalArtSystem EZ-USB Device
3-2          : ID 08bb:2902 Burr-Brown from TI               USB Audio CODEC
4-2          : ID 0461:4d22 Primax Electronics, Ltd
root@www:~# xm usb-list LightJockey
Idx BE  state usb-ver  BE-path
0   0   1     USB2.0  /local/domain/0/backend/vusb/3/0
port 1:
port 2:
port 3:
port 4:
root@www:~# xm usb-attach LightJockey 0 1 3-1
Unexpected error: <class
''xen.util.vusb_util.UsbDeviceParseError''>

Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
  File "/usr/lib/xen-4.1/bin/xm", line 8, in <module>
    main.main(sys.argv)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 3983,
in main
    _, rc = _run_cmd(cmd, cmd_name, args)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 4007,
in _run_cmd
    return True, cmd(args)
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/xm/main.py", line 3046,
in xm_usb_attach
    if vusb_util.bus_is_assigned(bus):
  File "/usr/lib/xen-4.1/bin/../lib/python/xen/util/vusb_util.py",
line 275, in bus_is_assigned
    raise UsbDeviceParseError("Can''t get assignment status:
(%s)." % bus)
xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device
info: Can''t get assignment status: (3-1).

I am assuming this means that I do not have the usbback drivers.  How
can I tell?  Where can I get them?  Are they packaged for Debian or
will I have to patch something?  There used to be a separate Xen
kernel but ever since I upgraded to wheezy the kernel appears to be
the stock one, yet everything still works with Xen hypervisor 4.1.2-6.

root@www:~# uname -a
Linux www 3.2.0-2-amd64 #1 SMP Fri Jun 1 17:49:08 UTC 2012 x86_64 GNU/Linux

Thanks in advance for you help James!

> 
> I did what you suggested and found a lot of the information I needed.
> I successfully created a host controller using root@www:~# xm usb-hc-
> create LightJockey 2 4 and the Add New Hardware wizard immediately
> showed up in my HVM.  I successfully installed the drivers there (which I
> believe to be usbfront drivers from GPLPV).  But now here''s my
current
> problem:
> 
> <snip>
> 
> xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device
> info: Can''t get assignment status: (3-1).
> 
> I am assuming this means that I do not have the usbback drivers.  How can I
> tell?  Where can I get them?  Are they packaged for Debian or will I have
to
> patch something?  There used to be a separate Xen kernel but ever since I
> upgraded to wheezy the kernel appears to be the stock one, yet everything
> still works with Xen hypervisor 4.1.2-6.
> 
I have something that might work. I had to tweak it a bit to compile under
3.2.0, but it seemed to work under 3.1.0 and the tweak was minor.

Download from http://www.meadowcourt.org/private/xen-usbback.tgz, untgz it, then
run make from inside the directory. You''ll need the current kernel
headers for your kernel to build but otherwise it''s just built
out-of-tree. That should give you a .ko module you can load.

I haven''t tested it under 3.2.0, so don''t go testing it on
anything important.

James

On Sun, Jul 1, 2012 at 11:03 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
> Are you definitely using the latest GPLPV?
>
> Once you have added the hc, you should see evidence of it in xenstore, eg
>
> xenstore-ls /local/domain/<domid>/device/vusb (I think it''s
vusb)
>
> James
I am using 0.11.0.357, which short of building from source was the
latest I could find.  I''m familiar with programming in C on both
Windows and Linux so if you think it might make a difference, I can
try pulling from mercurial.

On Sun, Jul 1, 2012 at 11:29 PM, Eric Lindsey <eslindsey@gmail.com>
wrote:
> On Sun, Jul 1, 2012 at 11:03 PM, James Harper
> <james.harper@bendigoit.com.au> wrote:
>> Are you definitely using the latest GPLPV?
>>
>> Once you have added the hc, you should see evidence of it in xenstore,
eg
>>
>> xenstore-ls /local/domain/<domid>/device/vusb (I think
it''s vusb)
>>
>> James
>
> I am using 0.11.0.357, which short of building from source was the
> latest I could find.  I''m familiar with programming in C on both
> Windows and Linux so if you think it might make a difference, I can
> try pulling from mercurial.
Crap sorry accidentally clicked Send instead of Save.  Here''s
xenstore-ls:

root@www:~# xenstore-ls /local/domain/1/device/vusb
0 = ""
 state = "4"
 backend-id = "0"
 backend = "/local/domain/0/backend/vusb/1/0"
 urb-ring-ref = "16364"
 conn-ring-ref = "16291"
 event-channel = "7"

On Fri, Jun 29, 2012 at 9:45 AM, Eric Lindsey <eslindsey@gmail.com>
wrote:
> I'm sorry for being unclear in my original message. I'm
experiencing the clock drift with and without the GPLPV drivers. However, I was
surprised that those drivers didn't include their own version of Linux's
independent_wallclock, which I presume takes care of the clock drift problem in
those operating systems (though I'll be the first to admit that's merely
an assumption and I've very little experience in this area). How can I solve
the clock drift problem, and keep my XP HVM synchronized with my dom0 hardware
clock (which does not suffer from drift)?
Have you tried tsc_native=1 yet? This will emulate synced RDTSC.
It'd be a bug in Xen if it didn't notice your TSC is broken...

-- 
Radosław Szkodziński

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

On Sun, Jul 8, 2012 at 4:24 PM, Radoslaw Szkodzinski
<astralstorm@gmail.com> wrote:
> On Fri, Jun 29, 2012 at 9:45 AM, Eric Lindsey <eslindsey@gmail.com>
wrote:
>> I'm sorry for being unclear in my original message. I'm
experiencing the clock drift with and without the GPLPV drivers. However, I was
surprised that those drivers didn't include their own version of Linux's
independent_wallclock, which I presume takes care of the clock drift problem in
those operating systems (though I'll be the first to admit that's merely
an assumption and I've very little experience in this area). How can I solve
the clock drift problem, and keep my XP HVM synchronized with my dom0 hardware
clock (which does not suffer from drift)?
>
> Have you tried tsc_native=1 yet? This will emulate synced RDTSC.
> It'd be a bug in Xen if it didn't notice your TSC is broken...
Sent too soon, it's now called tsc_mode. (see xmexample.hvm)

-- 
Radosław Szkodziński

_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users