Re: [Xen-users] Slow Windows XP 32-bit

[Peter Milesson <miles@xxxxxxxx>]

On 2013-09-27 13:42, James Harper wrote:
> > Hi folks,
> >
> > Here we go again with the sluggish performance of Windows XP 32-bit
> > under Xen 4.3.0. Up till now, I've tested it on AMD hardware, with the
> > parameter /PATCHTPR in the boot.ini file of the Windows XP installation.
> > It works really great, and Windows XP performance is relly outstanding,
> > almost better than on bare metal.
> >
> > When I use the parameter /PATCHTPR in the boot.ini of a Windows XP
> > installation under Intel hardware, it crashes utterly, almost
> > immediately during boot. What I could se from the little information
> > that's available, the /PATCHTPR parameter only applies to Windows XP
> > 32-bit, and Windows 2000 running under Xen on AMD hardware.
> >
> > The Intel Xen installation is almost identical to the one I described in
> > my first post a few days ago. It's really annoying and frustrating.
> >
> > I would be very grateful for some good advice, how to speed up Windows
> > XP 32-bit under Xen in Intel hardware.
> So it's definitely just as slow under Intel? For some reason I thought there 
> was some inherent speedup available for Intel these days that didn't need any 
> TPR patching.
>
> The problem is that 2000, XP, and 2003 (when older than SP2) access the Task 
> PRiority register lots, and doing so is very slow. The patchtpr option modifies 
> the windows kernel to try and find another way to emulate this without 
> requiring an emulation by Xen.
>
> First it checks the CPUID to see if the cpu supports a way to access the TPR 
> register via CR8. AMD allows this in 32 bit mode via a MOVE CR0 instruction, 
> prefixed with a LOCK. Intel has no such feature.
>
> If that option isn't available, it tries to map the vlapic to memory so it can 
> tinker with TPR that way.
>
> If all else fails, it caches any writes to the TPR register and only actually 
> writes when it would change the value of TPR. So you get a huge speedup for TPR 
> reads, and for any write to TPR that results in the same value being written. 
> It's not ideal but it does make a big difference.
>
> I need to know which of the last two is being selected on your system. I suspect it 
> will be the method that maps the vlapic. Can you install the debug version of the 
> drivers, then send me the output of /var/log/xen/qemu-<domu name>.log? There 
> should be some info logged in there about what patching is being done. There is a 
> chance that this logging is done too early and you'll need to attach a debugger to 
> capture that output, if so let me know and I should be able to give you a version 
> that patches later.
>
> If nothing else, I should be able to modify gplpv so that you can select the 
> last option and get some improvement, once I figure out what is going on.
>
> James
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users
Hi James,

I get exclusive access to the server tomorrow, and on Sunday, so perhaps 
I'll succeed to supply the log then.
The Windows domU not even starts when I use the /PATCHTPR parameter, 
crashes immediately after the short wait for F8. The GPLPV drivers used 
are 0.11.0.357. I tried to install the latest experimental drivers, but 
the installer waited for something indefinitely. Otherwise, the Windows 
XP performance is horrible, and about the same on the homebuilt AMD 
platform (6-core FX6100, AMD 970A chipsset, 12GB RAM) without PATCHTPR 
and the Dell server Intel platform (4-core Intel Xeon E31220, Intel C200 
chipsset, 12GB RAM).
I really appreciate your input.

I wish you a nice weekend,

Peter


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