
eslindsey at gmail
Jul 1, 2012, 6:04 PM
Post #4 of 9
(606 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
|