From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Venefax" Subject: Windows SMP Date: Sat, 27 Dec 2008 22:01:29 -0500 Message-ID: <036501c96898$959aaef0$c0d00cd0$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1554881586==" Return-path: Content-Language: en-us List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multipart message in MIME format. --===============1554881586== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0366_01C9686E.ACC4A6F0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0366_01C9686E.ACC4A6F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think that we need to tackle the absurd loss of performance that any Windows HVM incurs with more than one processor. I have measured it and it is amazing. I have an application that opens 15 independent network clients, and with one single processor and the Standard PC Hal, it takes a little over a minute to load the 15 clients and also to register with the SIP provider. If I leave that unchanged, I mean "ceteris paribus" , and only change the HAL to ACPI and add 8 processors, then the same operation takes over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. Right now I am about to test the MPS -Non-ACPI HAL, but the driver still create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any case, what can we do so any Windows virtual machine can achieve a "normal" performance, I mean, a linear performance when using more processors and not this declining curve that can kill any host. Federico ------=_NextPart_000_0366_01C9686E.ACC4A6F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think that we need to tackle the absurd loss of performance that any Windows HVM incurs with more than one processor. I = have measured it and it is amazing. I have an application that opens 15 = independent network clients, and with one single processor and the Standard PC Hal, it takes = a little over a minute to load the 15 clients and also to register with = the SIP provider. If I leave that unchanged, I mean “ceteris paribus” , and = only change the HAL to ACPI and add 8 processors, then the same operation = takes over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. = Right now I am about to test the MPS –Non-ACPI HAL, but the driver still = create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any = case, what can we do so any Windows virtual machine can achieve a = “normal” performance, I mean, a linear performance when using more processors and = not this declining curve that can kill any host.

Federico

------=_NextPart_000_0366_01C9686E.ACC4A6F0-- --===============1554881586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1554881586==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Randy McAnally" Subject: Re: Windows SMP Date: Sun, 28 Dec 2008 11:03:30 -0500 Message-ID: <20081228160032.M1477@fast-serv.com> References: <036501c96898$959aaef0$c0d00cd0$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2117919154==" Return-path: In-Reply-To: <036501c96898$959aaef0$c0d00cd0$@com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Venefax , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============2117919154== Content-Type: multipart/alternative; boundary="----=OPENWEBMAIL_ATT_0.840414278247533" This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.840414278247533 Content-Type: text/plain; charset=utf-8 I know this is probably not what you want to hear... but for our critical Windows applications we ended up switching to Citrix XenServer with the included PV drivers. The performance and stability is night and day -- a year later we have still had zero issues since the switch. It is truely production ready and performs very well in SMP. Although the open source PV drivers for XenSource have come a long way, they are still far from production-ready (even a year now since we tried them!) and should only be used in development or personal setups. -- Randy www.FastServ.com ---------- Original Message ----------- From: "Venefax" To: Sent: Sat, 27 Dec 2008 22:01:29 -0500 Subject: [Xen-devel] Windows SMP > I think that we need to tackle the absurd loss of performance that any Windows HVM incurs with more than one processor. I have measured it and it is amazing. I have an application that opens 15 independent network clients, and with one single processor and the Standard PC Hal, it takes a little over a minute to load the 15 clients and also to register with the SIP provider. If I leave that unchanged, I mean “ceteris paribus” , and only change the HAL to ACPI and add 8 processors, then the same operation takes over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. Right now I am about to test the MPS –Non-ACPI HAL, but the driver still create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any case, what can we do so any Windows virtual machine can achieve a “normal” performance, I mean, a linear performance when using more processors and not this declining curve that can kill any host. > Federico > ------- End of Original Message ------- ------=OPENWEBMAIL_ATT_0.840414278247533 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I know this is probably not what you want to hear... bu= t for our critical Windows applications we ended up switching to Citrix Xen= Server with the included PV drivers.=C2=A0 The performance and stability is= night and day -- a year later we have still had zero issues since the swit= ch.=C2=A0 It is truely production ready and performs very well in SMP.

Although the open source PV drivers for XenSource have = come a long way, they are still far from production-ready (even a year now = since we tried them!) and should only be used in development or personal se= tups.

--=20
Randy=20
www.FastServ.c= om

---------- Original Message -----------
From: "Venefax" <venefax@gmail.com>=20
To: <xen-devel@lists.xensource.com>=20
Sent: Sat, 27 Dec 2008 22:01:29 -0500=20
Subject: [Xen-devel] Windows SMP=20

> I think that we need to tackle the absurd loss of performance th= at any Windows HVM incurs with more than one processor. I have measured it = and it is amazing. I have an application that opens 15 independent network = clients, and with one single processor and the Standard PC Hal, it takes a = little over a minute to load the 15 clients and also to register with the S= IP provider. If I leave that unchanged, I mean =E2=80=9Cceteris paribus=E2= =80=9D , and only change the HAL to ACPI and add 8 processors, then the sam= e operation takes over 10 minutes. Hello!!! I am using the GPLVL drivers fr= om James Harper. Right now I am about to test the MPS =E2=80=93Non-ACPI HAL= , but the driver still create a BSOD. Maybe the problem is only ACPI, and n= ot MPS, who knows. In any case, what can we do so any Windows virtual machi= ne can achieve a =E2=80=9Cnormal=E2=80=9D performance, I mean, a linear per= formance when using more processors and not this declining curve that can k= ill any host.

=20
> Federico

=20
>=20

=C2=A0

------- End of Original Message -------

------=OPENWEBMAIL_ATT_0.840414278247533-- --===============2117919154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2117919154==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dirk Utterback" Subject: Re: Windows SMP Date: Sun, 28 Dec 2008 18:39:31 -0800 Message-ID: References: <036501c96898$959aaef0$c0d00cd0$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1408806110==" Return-path: In-Reply-To: <036501c96898$959aaef0$c0d00cd0$@com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Venefax Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1408806110== Content-Type: multipart/alternative; boundary="----=_Part_138143_10843538.1230518371184" ------=_Part_138143_10843538.1230518371184 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It seems something wrong. It is hard to achieve linear performance with more processors, but it should be at least something "normal". Another choice might be halsign turbogate drivers. I used it half a year ago, and i= t is stable and performance is really nice. 2008/12/27 Venefax > I think that we need to tackle the absurd loss of performance that any > Windows HVM incurs with more than one processor. I have measured it and i= t > is amazing. I have an application that opens 15 independent network clien= ts, > and with one single processor and the Standard PC Hal, it takes a little > over a minute to load the 15 clients and also to register with the SIP > provider. If I leave that unchanged, I mean "ceteris paribus" , and only > change the HAL to ACPI and add 8 processors, then the same operation take= s > over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. > Right now I am about to test the MPS =96Non-ACPI HAL, but the driver stil= l > create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In > any case, what can we do so any Windows virtual machine can achieve a > "normal" performance, I mean, a linear performance when using more > processors and not this declining curve that can kill any host. > > Federico > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > ------=_Part_138143_10843538.1230518371184 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It seems something wrong. It is hard to achieve linear perform= ance with more processors, but it should be at least something "normal= ". Another choice might be halsign turbogate drivers. I used it = half a year ago, and it is stable and performance is really nice.

2008/12/27 Venefax <venefax@gmail.com>

I think that we need to tackle the absurd loss of performance that any Windows HVM incurs with more than one processor. I hav= e measured it and it is amazing. I have an application that opens 15 independ= ent network clients, and with one single processor and the Standard PC Hal, it takes a little over a minute to load the 15 clients and also to register with the S= IP provider. If I leave that unchanged, I mean "ceteris paribus" , and only change the HAL to ACPI and add 8 processors, then the same operation takes = over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. Right = now I am about to test the MPS =96Non-ACPI HAL, but the driver still create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any case, = what can we do so any Windows virtual machine can achieve a "normal" performance, I mean, a linear performance when using more processors and no= t this declining curve that can kill any host.

Federico

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.= com
http://l= ists.xensource.com/xen-devel

------=_Part_138143_10843538.1230518371184-- --===============1408806110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1408806110==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Venefax" Subject: RE: Windows SMP Date: Sun, 28 Dec 2008 21:48:44 -0500 Message-ID: <03e401c9695f$f7ebb8c0$e7c32a40$@com> References: <036501c96898$959aaef0$c0d00cd0$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2033863167==" Return-path: In-Reply-To: Content-Language: en-us List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: 'Dirk Utterback' Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a multipart message in MIME format. --===============2033863167== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E5_01C96936.0F15B0C0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_03E5_01C96936.0F15B0C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The problem is not SMP, is ACPI. I installed a non-ACPI Hal, but SMP capable, and the performance went right up with 4 virtual processors. I hope the developers can look into this mess. Federico From: Dirk Utterback [mailto:dirk.utterback@gmail.com] Sent: Sunday, December 28, 2008 9:40 PM To: Venefax Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] Windows SMP It seems something wrong. It is hard to achieve linear performance with more processors, but it should be at least something "normal". Another choice might be halsign turbogate drivers. I used it half a year ago, and it is stable and performance is really nice. 2008/12/27 Venefax I think that we need to tackle the absurd loss of performance that any Windows HVM incurs with more than one processor. I have measured it and it is amazing. I have an application that opens 15 independent network clients, and with one single processor and the Standard PC Hal, it takes a little over a minute to load the 15 clients and also to register with the SIP provider. If I leave that unchanged, I mean "ceteris paribus" , and only change the HAL to ACPI and add 8 processors, then the same operation takes over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. Right now I am about to test the MPS -Non-ACPI HAL, but the driver still create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any case, what can we do so any Windows virtual machine can achieve a "normal" performance, I mean, a linear performance when using more processors and not this declining curve that can kill any host. Federico _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ------=_NextPart_000_03E5_01C96936.0F15B0C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The problem is not SMP, is ACPI. I installed a non-ACPI = Hal, but SMP capable, and the performance went right up with 4 virtual = processors.

I hope the developers can look into this = mess.

Federico

From:= Dirk = Utterback [mailto:dirk.utterback@gmail.com]
Sent: Sunday, December 28, 2008 9:40 PM
To: Venefax
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Windows SMP

It = seems something wrong. It is hard to achieve linear performance with more processors, = but it should be at least something "normal". Another choice = might be halsign turbogate drivers. I used it half a year ago, and it is stable = and performance is really nice.

2008/12/27 Venefax <venefax@gmail.com>

I think that we need to tackle the absurd loss of performance that = any Windows HVM incurs with more than one processor. I have measured it and = it is amazing. I have an application that opens 15 independent network = clients, and with one single processor and the Standard PC Hal, it takes a little = over a minute to load the 15 clients and also to register with the SIP = provider. If I leave that unchanged, I mean "ceteris paribus" , and only = change the HAL to ACPI and add 8 processors, then the same operation takes over 10 minutes. Hello!!! I am using the GPLVL drivers from James Harper. Right = now I am about to test the MPS –Non-ACPI HAL, but the driver still = create a BSOD. Maybe the problem is only ACPI, and not MPS, who knows. In any case, = what can we do so any Windows virtual machine can achieve a "normal" performance, I mean, a linear performance when using more processors and = not this declining curve that can kill any host.

Federico

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.c= om
http://lists.xensource.com/xen-devel

------=_NextPart_000_03E5_01C96936.0F15B0C0-- --===============2033863167== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============2033863167==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 13:53:15 +1100 Message-ID: References: <036501c96898$959aaef0$c0d00cd0$@com> <03e401c9695f$f7ebb8c0$e7c32a40$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: <03e401c9695f$f7ebb8c0$e7c32a40$@com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >=20 > The problem is not SMP, is ACPI. I installed a non-ACPI Hal, but SMP > capable, and the performance went right up with 4 virtual processors. >=20 > I hope the developers can look into this mess. >=20 Can you have ACPI enabled but APIC disabled, or is that not a valid configuration? Or the other way around, can you have ACPI disabled but APIC enabled? Maybe the APIC emulation is causing a performance loss? James From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Venefax" Subject: RE: Windows SMP Date: Sun, 28 Dec 2008 21:59:44 -0500 Message-ID: <03e901c96961$81b81980$85284c80$@com> References: <036501c96898$959aaef0$c0d00cd0$@com> <03e401c9695f$f7ebb8c0$e7c32a40$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-us List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: 'James Harper' , 'Dirk Utterback' Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I had to disable both, and PAE. Only APIC=0 would not make any difference. I will some further testing with Citrix Xenserver 5, using the same virtual machine and another copy with their vmpd drivers. I bet that there is no difference in performance. It seems to be a Xen architectural issue. Any ideas? -----Original Message----- From: James Harper [mailto:james.harper@bendigoit.com.au] Sent: Sunday, December 28, 2008 9:53 PM To: Venefax; Dirk Utterback Cc: xen-devel@lists.xensource.com Subject: RE: [Xen-devel] Windows SMP > > The problem is not SMP, is ACPI. I installed a non-ACPI Hal, but SMP > capable, and the performance went right up with 4 virtual processors. > > I hope the developers can look into this mess. > Can you have ACPI enabled but APIC disabled, or is that not a valid configuration? Or the other way around, can you have ACPI disabled but APIC enabled? Maybe the APIC emulation is causing a performance loss? James From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dirk Utterback" Subject: Re: Windows SMP Date: Sun, 28 Dec 2008 22:46:54 -0800 Message-ID: References: <036501c96898$959aaef0$c0d00cd0$@com> <03e401c9695f$f7ebb8c0$e7c32a40$@com> <03e901c96961$81b81980$85284c80$@com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0223199765==" Return-path: In-Reply-To: <03e901c96961$81b81980$85284c80$@com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Venefax Cc: James Harper , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0223199765== Content-Type: multipart/alternative; boundary="----=_Part_138856_13530747.1230533214971" ------=_Part_138856_13530747.1230533214971 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What is your Xen and Windows version? I have been using CentOS5, and Windows XP as the guest. It works fine with 2 vcpu for Windows in my setup(apic=1, acpi=1). Dirk On Sun, Dec 28, 2008 at 6:59 PM, Venefax wrote: > I had to disable both, and PAE. Only APIC=0 would not make any difference. > I > will some further testing with Citrix Xenserver 5, using the same virtual > machine and another copy with their vmpd drivers. I bet that there is no > difference in performance. It seems to be a Xen architectural issue. Any > ideas? > > -----Original Message----- > From: James Harper [mailto:james.harper@bendigoit.com.au] > Sent: Sunday, December 28, 2008 9:53 PM > To: Venefax; Dirk Utterback > Cc: xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] Windows SMP > > > > > The problem is not SMP, is ACPI. I installed a non-ACPI Hal, but SMP > > capable, and the performance went right up with 4 virtual processors. > > > > I hope the developers can look into this mess. > > > > Can you have ACPI enabled but APIC disabled, or is that not a valid > configuration? > > Or the other way around, can you have ACPI disabled but APIC enabled? > > Maybe the APIC emulation is causing a performance loss? > > James > > ------=_Part_138856_13530747.1230533214971 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What is your Xen and Windows version? I have been using CentOS5, and Windows XP as the guest.
It works fine with 2 vcpu for Windows in my setup(apic=1, acpi=1).

Dirk

On Sun, Dec 28, 2008 at 6:59 PM, Venefax <venefax@gmail.com> wrote:

I had to disable both, and PAE. Only APIC=0 would not make any difference. I
will some further testing with Citrix Xenserver 5, using the same virtual
machine and another copy with their vmpd drivers. I bet that there is no
difference in performance. It seems to be a Xen architectural issue. Any
ideas?

-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au]
Sent: Sunday, December 28, 2008 9:53 PM
To: Venefax; Dirk Utterback
Cc: xen-devel@lists.xensource.com

Subject: RE: [Xen-devel] Windows SMP

>
> The problem is not SMP, is ACPI. I installed a non-ACPI Hal, but SMP
> capable, and the performance went right up with 4 virtual processors.
>
> I hope the developers can look into this mess.
>

Can you have ACPI enabled but APIC disabled, or is that not a valid
configuration?

Or the other way around, can you have ACPI disabled but APIC enabled?

Maybe the APIC emulation is causing a performance loss?

James

------=_Part_138856_13530747.1230533214971-- --===============0223199765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0223199765==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 08:14:02 +0000 Message-ID: References: <03e901c96961$81b81980$85284c80$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <03e901c96961$81b81980$85284c80$@com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Venefax , 'James Harper' , 'Dirk Utterback' Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 29/12/2008 02:59, "Venefax" wrote: > I had to disable both, and PAE. Only APIC=0 would not make any difference. I > will some further testing with Citrix Xenserver 5, using the same virtual > machine and another copy with their vmpd drivers. I bet that there is no > difference in performance. It seems to be a Xen architectural issue. Any > ideas? The problem is almost certainly APIC related. APIC=0 actually has no effect for a multi-processor HVM guest, since APICs are architecturally absolutely required in x86 multi-processor systems. The problem is most likely lots of emulated APIC TPR writes slowing things down. Possible fixes: 1. Run a Windows guest with the 'lazy TPR' optimisation -- w2k3sp2+, w2k8, vista. Or run 64-bit Windows which will write TPR in a different way which most Intel/AMD CPUs can virtualise efficiently. 2. Run a new enough Intel processor which has automatic TPR handling even for 32-bit Windows guests. 3. Run Citrix drivers which patch Windows to avoid TPR writes. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 19:20:03 +1100 Message-ID: References: <03e901c96961$81b81980$85284c80$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > I had to disable both, and PAE. Only APIC=3D0 would not make any > difference. I > > will some further testing with Citrix Xenserver 5, using the same > virtual > > machine and another copy with their vmpd drivers. I bet that there is no > > difference in performance. It seems to be a Xen architectural issue. Any > > ideas? >=20 > The problem is almost certainly APIC related. APIC=3D0 actually has no > effect > for a multi-processor HVM guest, since APICs are architecturally > absolutely > required in x86 multi-processor systems. >=20 > The problem is most likely lots of emulated APIC TPR writes slowing things > down. Possible fixes: > 1. Run a Windows guest with the 'lazy TPR' optimisation -- w2k3sp2+, > w2k8, > vista. Or run 64-bit Windows which will write TPR in a different way which > most Intel/AMD CPUs can virtualise efficiently. > 2. Run a new enough Intel processor which has automatic TPR handling even > for 32-bit Windows guests. > 3. Run Citrix drivers which patch Windows to avoid TPR writes. >=20 Can you elaborate on that last point? Does that pass WHQL? I think that 'venefax' is running Windows 2003sp2... does that exclude 'lazy TPR' fix as an option or does it need enabling somehow? Thanks James From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 08:37:49 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 29/12/2008 08:20, "James Harper" wrote: >> 3. Run Citrix drivers which patch Windows to avoid TPR writes. > Can you elaborate on that last point? Does that pass WHQL? The WHQL tests are oblivious to it. It's just a patching of mmio writes to the APIC TPR register. > I think that 'venefax' is running Windows 2003sp2... does that exclude > 'lazy TPR' fix as an option or does it need enabling somehow? If he's running sp2 then I think TPR problems can be discounted. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 19:47:54 +1100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > On 29/12/2008 08:20, "James Harper" wrote: >=20 > >> 3. Run Citrix drivers which patch Windows to avoid TPR writes. >=20 > > Can you elaborate on that last point? Does that pass WHQL? >=20 > The WHQL tests are oblivious to it. It's just a patching of mmio writes to > the APIC TPR register. >=20 Looking at the way KVM does it, it appears to detect writes to the TPR register when they are trapped, and then give the DomU (or whatever KVM calls it) the address of the instruction so that the DomU driver can then patch it. Is that what Citrix is doing? Does the current xensource tree have such a mechanism in it? Thanks James From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 08:56:18 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 29/12/2008 08:47, "James Harper" wrote: >> The WHQL tests are oblivious to it. It's just a patching of mmio >> writes to the APIC TPR register. > > Looking at the way KVM does it, it appears to detect writes to the TPR > register when they are trapped, and then give the DomU (or whatever KVM > calls it) the address of the instruction so that the DomU driver can > then patch it. Is that what Citrix is doing? Does the current xensource > tree have such a mechanism in it? The result is the same, but there's no hypervisor component, so none of it is open sourced. You could get similar results by putting static Windows-kernel-specific fixup tables in your drivers, or I'd be open to having a KVM type of interaction between Xen and your GPLPV drivers. Putting the payload in the generic virtual BIOS seemed kind of gross to me. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 20:03:21 +1100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > On 29/12/2008 08:47, "James Harper" wrote: >=20 > >> The WHQL tests are oblivious to it. It's just a patching of mmio > >> writes to the APIC TPR register. > > > > Looking at the way KVM does it, it appears to detect writes to the TPR > > register when they are trapped, and then give the DomU (or whatever KVM > > calls it) the address of the instruction so that the DomU driver can > > then patch it. Is that what Citrix is doing? Does the current xensource > > tree have such a mechanism in it? >=20 > The result is the same, but there's no hypervisor component, so none of it > is open sourced. :) > You could get similar results by putting static Windows-kernel-specific > fixup tables in your drivers, As in 'write bytes to offset x into kernel function y', with x depending on the exact kernel build? Wouldn't the rootkit detectors complain about that? > or I'd be open to having a KVM type of > interaction between Xen and your GPLPV drivers. Putting the payload in the > generic virtual BIOS seemed kind of gross to me. Is it possible for a virtualised DomU to trap the MMIO write itself, or can it only be trapped by the hypervisor? Btw, is it the vmexit that is slow about these TPR writes, or is it the writes themselves? Thanks James From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 09:16:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 29/12/2008 09:03, "James Harper" wrote: >> You could get similar results by putting static > Windows-kernel-specific >> fixup tables in your drivers, > > As in 'write bytes to offset x into kernel function y', with x depending > on the exact kernel build? Wouldn't the rootkit detectors complain about > that? I'm not actually sure on rootkit-detector compatibility with this approach. I know that the built-in tripwire capabilities of some 64-bit Windows versions would be a problem, but then they tend to have lazy TPR, and also they write to the TPR with MOV CR8, which can usually be handled efficiently by HVM-capable CPUs anyway, so no patching is required. Any software-based approach is going to involve patching, so I'd cross the rootkit-detector bridge when/if we come to it. I haven't heard or read of any complaints in this regard so far. >> or I'd be open to having a KVM type of >> interaction between Xen and your GPLPV drivers. Putting the payload in > the >> generic virtual BIOS seemed kind of gross to me. > > Is it possible for a virtualised DomU to trap the MMIO write itself, or > can it only be trapped by the hypervisor? It could, by trapping all accesses to the APIC page (remove mapping, hook page-fault handler). It's going to be much easier to get help from the hypervisor! > Btw, is it the vmexit that is slow about these TPR writes, or is it the > writes themselves? Both. As well as the VMEXIT you have a run through the instruction emulator and into the apic device model. It sucks pretty bad if you do it often. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 20:40:48 +1100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > Is it possible for a virtualised DomU to trap the MMIO write itself, or > > can it only be trapped by the hypervisor? >=20 > It could, by trapping all accesses to the APIC page (remove mapping, hook > page-fault handler). It's going to be much easier to get help from the > hypervisor! Hmmm... maybe easier with the hypervisor but by trapping writes I could do it all in my drivers. Assuming the hypervisor route, if I understand correctly it could go like this: . develop a mechanism for qemu's TPR write emulation to also signal my drivers somehow. This signalling mechanism would have to be low overhead, but could also be pretty lazy (if these TPR writes are happening often then it doesn't matter if we miss a few as we'll patch them all pretty quickly) . the PV drivers get the signal, perform some validation on the instruction that caused the TPR write to make sure it's patchable, and then overwrite the instruction with a call to my own routine, making sure that this is done in an SMP safe way and taking care of caching etc... . My own routine does ??? (I haven't figured this out exactly, but there is plenty of code out there that does it already) Thinking about this some more... could it work the other way around instead: . My drivers publish to qemu (somehow... io space write maybe???) the required patch for the mmio write instruction, eg a patch request might look like: <01> (magic number indicating a TPR write patch) <05> (length) <01><02><03><04><05> (code to replace the TPR write instruction with) . Qemu stores the above in a table, and every time an mmio write instruction for the TPR register occurs which is exactly 5 bytes in length, patch the instruction with the code given > > Btw, is it the vmexit that is slow about these TPR writes, or is it the > > writes themselves? >=20 > Both. As well as the VMEXIT you have a run through the instruction > emulator > and into the apic device model. It sucks pretty bad if you do it often. I see. It's the sum of a whole load of tiny overheads that adds up... Thanks James From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 09:58:05 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 29/12/2008 09:40, "James Harper" wrote: > Assuming the hypervisor route, if I understand correctly it could go > like this: Either of your described approaches could work. This doesn't involve qemu at all, since APIC emulation is done within Xen. So it'll be a new hvm_op hypercall either way. Getting Xen to do the patching isn't a bad idea. Might also be worth looking at how KVM does it to get some further ideas. I don't think your patched routine has to be any more complex than filtering out TPR writes which don't change the TPR value. Again you could check KVM for this. And of course the TPR write in your patch routine should be skipped by the trap-and-patch mechanism. :-) >> Both. As well as the VMEXIT you have a run through the instruction >> emulator >> and into the apic device model. It sucks pretty bad if you do it > often. > > I see. It's the sum of a whole load of tiny overheads that adds up... Two fairly big overheads. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Harper" Subject: RE: Windows SMP Date: Mon, 29 Dec 2008 21:01:13 +1100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Venefax , Dirk Utterback Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > On 29/12/2008 09:40, "James Harper" wrote: >=20 > > Assuming the hypervisor route, if I understand correctly it could go > > like this: >=20 > Either of your described approaches could work. This doesn't involve qemu > at > all, since APIC emulation is done within Xen. So it'll be a new hvm_op > hypercall either way. Getting Xen to do the patching isn't a bad idea. > Might > also be worth looking at how KVM does it to get some further ideas. >=20 Oh. I had a quick look at hw/apic.c and assumed that's where the action was... guess I'll look in xen then! Thanks James From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew Lyon" Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 21:40:37 +0000 Message-ID: References: <03e901c96961$81b81980$85284c80$@com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On Mon, Dec 29, 2008 at 8:14 AM, Keir Fraser wrote: > On 29/12/2008 02:59, "Venefax" wrote: > >> I had to disable both, and PAE. Only APIC=0 would not make any difference. I >> will some further testing with Citrix Xenserver 5, using the same virtual >> machine and another copy with their vmpd drivers. I bet that there is no >> difference in performance. It seems to be a Xen architectural issue. Any >> ideas? > > The problem is almost certainly APIC related. APIC=0 actually has no effect > for a multi-processor HVM guest, since APICs are architecturally absolutely > required in x86 multi-processor systems. > > The problem is most likely lots of emulated APIC TPR writes slowing things > down. Possible fixes: > 1. Run a Windows guest with the 'lazy TPR' optimisation -- w2k3sp2+, w2k8, > vista. Or run 64-bit Windows which will write TPR in a different way which > most Intel/AMD CPUs can virtualise efficiently. > 2. Run a new enough Intel processor which has automatic TPR handling even > for 32-bit Windows guests. Does "PTR handling" have a cpu feature flag I can grep for in /proc/cpuinfo, or perhaps there is a list of cpus that support that feature? I run Xen on two systems, a dual Xeon 5420 and a Core 2 Quad, neither seem to suffer from bad performance with SMP Windows hvm's but most of the windows hvm's I run are not heavily loaded so I would like to know if my system is likely to suffer from this problem as it would probably become noticible once load increases. thx Andy > 3. Run Citrix drivers which patch Windows to avoid TPR writes. > > -- Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Mon, 29 Dec 2008 21:57:44 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On 29/12/2008 21:40, "Andrew Lyon" wrote: > Does "PTR handling" have a cpu feature flag I can grep for in > /proc/cpuinfo, or perhaps there is a list of cpus that support that > feature? No it's not a CPUID feature and hence not visible via /proc/cpuinfo. Xen could print out if it detects the feature, but it doesn't currently. :-) -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew Lyon" Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 10:34:23 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On Mon, Dec 29, 2008 at 9:57 PM, Keir Fraser wrote: > On 29/12/2008 21:40, "Andrew Lyon" wrote: > >> Does "PTR handling" have a cpu feature flag I can grep for in >> /proc/cpuinfo, or perhaps there is a list of cpus that support that >> feature? > > No it's not a CPUID feature and hence not visible via /proc/cpuinfo. Xen > could print out if it detects the feature, but it doesn't currently. :-) Hmm, that would be very useful. As its not a cpuid feature I guess I will have to check the Intel manuals for each cpu model, do you know what the feature is described as in Intel documentation? > > -- Keir > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 11:04:33 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On 30/12/2008 10:34, "Andrew Lyon" wrote: >> No it's not a CPUID feature and hence not visible via /proc/cpuinfo. Xen >> could print out if it detects the feature, but it doesn't currently. :-) > > Hmm, that would be very useful. > > As its not a cpuid feature I guess I will have to check the Intel > manuals for each cpu model, do you know what the feature is described > as in Intel documentation? In the architecture manual it is known as apic-access virtualisation. I don't know whether it would be a headline feature in a processor's data sheet. -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew Lyon" Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 12:41:02 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On Tue, Dec 30, 2008 at 11:04 AM, Keir Fraser wrote: > On 30/12/2008 10:34, "Andrew Lyon" wrote: > >>> No it's not a CPUID feature and hence not visible via /proc/cpuinfo. Xen >>> could print out if it detects the feature, but it doesn't currently. :-) >> >> Hmm, that would be very useful. >> >> As its not a cpuid feature I guess I will have to check the Intel >> manuals for each cpu model, do you know what the feature is described >> as in Intel documentation? > > In the architecture manual it is known as apic-access virtualisation. I > don't know whether it would be a headline feature in a processor's data > sheet. Can you point me to the code where apic-access virtualisation is used? Displaying a message might be a nice small improvement for me to figure out and contribute. > > -- Keir > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ian Pratt" Subject: RE: Windows SMP Date: Tue, 30 Dec 2008 13:15:17 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Andrew Lyon Cc: Ian Pratt , James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org > > As its not a cpuid feature I guess I will have to check the Intel > > manuals for each cpu model, do you know what the feature is described > > as in Intel documentation? >=20 > In the architecture manual it is known as apic-access virtualisation. I > don't know whether it would be a headline feature in a processor's data > sheet. I believe Intel's marketing moniker for the feature is "FlexPriority". Ian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 14:41:56 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: James Harper , Dirk Utterback , xen-devel@lists.xensource.com, Venefax List-Id: xen-devel@lists.xenproject.org On 30/12/2008 12:41, "Andrew Lyon" wrote: >> In the architecture manual it is known as apic-access virtualisation. I >> don't know whether it would be a headline feature in a processor's data >> sheet. > > Can you point me to the code where apic-access virtualisation is used? > Displaying a message might be a nice small improvement for me to > figure out and contribute. You can make use of the macro cpu_has_vmx_virtualize_apic_accesses to control a printk() at the end of xen/arch/x86/hvm/vmx/vmcs.c:vmx_init_vmcs_config(). -- Keir From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Huang Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 10:58:26 -0600 Message-ID: <495A5332.1020204@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: xen-devel@lists.xensource.com, Dirk Utterback , Keir Fraser , Venefax List-Id: xen-devel@lists.xenproject.org James, Travis Betak released a Windows driver which patches Windows TPR accesses. You can find it from http://sourceforge.net/projects/amdvopt/. The code would be useful as a reference. src link: svn co https://amdvopt.svn.sourceforge.net/svnroot/amdvopt amdvopt Thanks, -Wei James Harper wrote: >> On 29/12/2008 08:20, "James Harper" > wrote: >>>> 3. Run Citrix drivers which patch Windows to avoid TPR writes. >>> Can you elaborate on that last point? Does that pass WHQL? >> The WHQL tests are oblivious to it. It's just a patching of mmio > writes to >> the APIC TPR register. >> > > Looking at the way KVM does it, it appears to detect writes to the TPR > register when they are trapped, and then give the DomU (or whatever KVM > calls it) the address of the instruction so that the DomU driver can > then patch it. Is that what Citrix is doing? Does the current xensource > tree have such a mechanism in it? > > Thanks > > James > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Windows SMP Date: Tue, 30 Dec 2008 22:24:16 +0000 Message-ID: References: <495A5332.1020204@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <495A5332.1020204@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Wei Huang , James Harper Cc: xen-devel@lists.xensource.com, Dirk Utterback , Venefax List-Id: xen-devel@lists.xenproject.org That looks like it could be a nice drop-in piece of code! -- Keir On 30/12/2008 16:58, "Wei Huang" wrote: > James, > > Travis Betak released a Windows driver which patches Windows TPR > accesses. You can find it from http://sourceforge.net/projects/amdvopt/. > The code would be useful as a reference. src link: > > svn co https://amdvopt.svn.sourceforge.net/svnroot/amdvopt amdvopt > > Thanks, > > -Wei > > > James Harper wrote: >>> On 29/12/2008 08:20, "James Harper" >> wrote: >>>>> 3. Run Citrix drivers which patch Windows to avoid TPR writes. >>>> Can you elaborate on that last point? Does that pass WHQL? >>> The WHQL tests are oblivious to it. It's just a patching of mmio >> writes to >>> the APIC TPR register. >>> >> >> Looking at the way KVM does it, it appears to detect writes to the TPR >> register when they are trapped, and then give the DomU (or whatever KVM >> calls it) the address of the instruction so that the DomU driver can >> then patch it. Is that what Citrix is doing? Does the current xensource >> tree have such a mechanism in it? >> >> Thanks >> >> James >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tian, Kevin" Subject: RE: Windows SMP Date: Wed, 31 Dec 2008 10:35:20 +0800 Message-ID: <0A882F4D99BBF6449D58E61AAFD7EDD603BB4A2D@pdsmsx502.ccr.corp.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: 'James Harper' , Keir Fraser