Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Xen: Users

GPLPV, clock drift and PVUSB in Windows XP HVM

 

 

Xen users RSS feed   Index | Next | Previous | View Threaded


eslindsey at gmail

Jun 28, 2012, 10:20 AM

Post #1 of 9 (709 views)
Permalink
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
_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


james.harper at bendigoit

Jun 29, 2012, 12:18 AM

Post #2 of 9 (671 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

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

_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


eslindsey at gmail

Jun 29, 2012, 12:45 AM

Post #3 of 9 (663 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

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 [at] bendigoit> 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

_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


eslindsey at gmail

Jul 1, 2012, 6:04 PM

Post #4 of 9 (651 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

On Fri, Jun 29, 2012 at 3:45 AM, Eric Lindsey <eslindsey [at] gmail> 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 [at] bendigoit> 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 [at] ww:~# 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 [at] ww:~# 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 [at] ww:~# 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 [at] ww:~# xm usb-attach LightJockey 0 1 3-1
Unexpected error: <class 'xen.util.vusb_util.UsbDeviceParseError'>

Please report to xen-devel [at] lists
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 [at] ww:~# 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!

_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


james.harper at bendigoit

Jul 1, 2012, 6:28 PM

Post #5 of 9 (652 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

>
> I did what you suggested and found a lot of the information I needed.
> I successfully created a host controller using root [at] ww:~# 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


_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


eslindsey at gmail

Jul 1, 2012, 8:29 PM

Post #6 of 9 (644 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

On Sun, Jul 1, 2012 at 11:03 PM, James Harper
<james.harper [at] bendigoit> 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.

_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


eslindsey at gmail

Jul 1, 2012, 8:31 PM

Post #7 of 9 (648 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

On Sun, Jul 1, 2012 at 11:29 PM, Eric Lindsey <eslindsey [at] gmail> wrote:
> On Sun, Jul 1, 2012 at 11:03 PM, James Harper
> <james.harper [at] bendigoit> 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 [at] ww:~# 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"

_______________________________________________
Xen-users mailing list
Xen-users [at] lists
http://lists.xen.org/xen-users


astralstorm at gmail

Jul 8, 2012, 7:24 AM

Post #8 of 9 (597 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

On Fri, Jun 29, 2012 at 9:45 AM, Eric Lindsey <eslindsey [at] gmail> 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 [at] lists
http://lists.xen.org/xen-users


astralstorm at gmail

Jul 8, 2012, 7:25 AM

Post #9 of 9 (604 views)
Permalink
Re: GPLPV, clock drift and PVUSB in Windows XP HVM [In reply to]

On Sun, Jul 8, 2012 at 4:24 PM, Radoslaw Szkodzinski
<astralstorm [at] gmail> wrote:
> On Fri, Jun 29, 2012 at 9:45 AM, Eric Lindsey <eslindsey [at] gmail> 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 [at] lists
http://lists.xen.org/xen-users

Xen users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.