Re: [Xen-users] GPLPV, clock drift and PVUSB in Windows XP HVM

[Eric Lindsey <eslindsey@xxxxxxxxx>]

On Fri, Jun 29, 2012 at 3:45 AM, Eric Lindsey <eslindsey@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 
> 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@xxxxxxxxxxxxxxxxxxx
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!

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