qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests.
@ 2007-08-26  9:10 Igor Lvovsky
  2007-08-26  9:51 ` Andreas Färber
  2007-08-27 16:22 ` Carlo Marcelo Arenas Belon
  0 siblings, 2 replies; 3+ messages in thread
From: Igor Lvovsky @ 2007-08-26  9:10 UTC (permalink / raw)
  To: qemu-devel


[-- Attachment #1.1: Type: text/plain, Size: 2446 bytes --]

>> Does anybody know what's going on? Is SMP support working at the moment?

 

>SMP works fine on Sparc32. Performance isn't great because the CPUs are not halted in SMP mode but they busy loop when idle.

 

  Hi,

I sent this patch before, but probably it was dropped.

I hope it will help.

 

            Regards,

 Igor Lvovsky

 

________________________________

From: kvm-devel-bounces@lists.sourceforge.net [mailto:kvm-devel-bounces@lists.sourceforge.net] On Behalf Of Igor Lvovsky
Sent: Tuesday, August 14, 2007 2:39 PM
To: kvm-devel@lists.sourceforge.net; qemu-devel@nongnu.org; bochs-developers@lists.sourceforge.net
Subject: [kvm-devel] CPU consumption for SMP windows guests.

 

  Hi,

I tried to play recently with the ACPI to solve the "CPU consumption for SMP windows guests" problem that was discussed in kvm forum.

 

The current problem is:

The windows UP guest with latest Bochs bios work well - with reasonable CPU usage.

The windows SMP guest with same bios, consumes a lot of CPU.

 

As it was mentioned in forum (by Avi) it looks like the problem in the windows Idle loop, that spinning instead of executing a 'hlt' instruction.

So, the solution lies in ACPI area.  We need to modify a little bit ACPI tables as following:

1.	We need expose the CPUs via DSDT table (After this patch we can support up to 16 CPUs)

- It's immediately solving the problem with the SMP guests. Now, with new bios windows run with reasonable CPU consuming.

 

Notes: The UP guest uses the HAL with the halaacpi.dll and windows Idle loop work fine without ACPI support (I mean bios don't expose the CPU as ACPI device).

But, the SMP guest uses HAL with the halmacpi.dll and it looks like windows can't work properly without ACPI support. 

In additional, once you run the image as SMP (the windows will update the HAL dll) you can't run it again as UP (truly you can, but the CPU consuming will huge).  

The reason for this behavior looks like windows bug; windows can't revert the HAL to the proper dll for UP.

So, the next case fixes this new UP problem and allows running UP guests with SMP/UP HAL with good CPU consumption.

 

2.	We need to disable support of C2 and C3 CPU states via FADT (P_LVL2_LAT and P_LVL3_LAT fields).

 

I attached the patch for BOCHS bios and compiled bios.bin.

 

     Regards,

                        Igor Lvovsky


[-- Attachment #1.2: Type: text/html, Size: 11861 bytes --]

[-- Attachment #2: bios.bin --]
[-- Type: application/octet-stream, Size: 131072 bytes --]

[-- Attachment #3: cpu-consumption.diff --]
[-- Type: application/octet-stream, Size: 2727 bytes --]

Index: acpi-dsdt.dsl
===================================================================
RCS file: /cvsroot/bochs/bochs/bios/acpi-dsdt.dsl,v
retrieving revision 1.1
diff -u -r1.1 acpi-dsdt.dsl
--- acpi-dsdt.dsl	28 Sep 2006 18:56:20 -0000	1.1
+++ acpi-dsdt.dsl	14 Aug 2007 11:25:04 -0000
@@ -25,6 +25,26 @@
     0x1                 // OEM Revision
     )
 {
+    Scope (_PR)
+    {
+        Processor (CPU0, 0x00, 0x0000b010, 0x06) {}
+        Processor (CPU1, 0x01, 0x0000b010, 0x06) {}
+        Processor (CPU2, 0x02, 0x0000b010, 0x06) {}
+        Processor (CPU3, 0x03, 0x0000b010, 0x06) {}
+        Processor (CPU4, 0x04, 0x0000b010, 0x06) {}
+        Processor (CPU5, 0x05, 0x0000b010, 0x06) {}
+        Processor (CPU6, 0x06, 0x0000b010, 0x06) {}
+        Processor (CPU7, 0x07, 0x0000b010, 0x06) {}
+        Processor (CPU8, 0x08, 0x0000b010, 0x06) {}
+        Processor (CPU9, 0x09, 0x0000b010, 0x06) {}
+        Processor (CPUA, 0x0a, 0x0000b010, 0x06) {}
+        Processor (CPUB, 0x0b, 0x0000b010, 0x06) {}
+        Processor (CPUC, 0x0c, 0x0000b010, 0x06) {}
+        Processor (CPUD, 0x0d, 0x0000b010, 0x06) {}
+        Processor (CPUE, 0x0e, 0x0000b010, 0x06) {}
+        Processor (CPUF, 0x0f, 0x0000b010, 0x06) {}
+    }
+
     Scope (\)
     {
         /* CMOS memory access */
Index: rombios32.c
===================================================================
RCS file: /cvsroot/bochs/bochs/bios/rombios32.c,v
retrieving revision 1.11
diff -u -r1.11 rombios32.c
--- rombios32.c	3 Aug 2007 13:56:13 -0000	1.11
+++ rombios32.c	14 Aug 2007 11:25:05 -0000
@@ -20,6 +20,7 @@
 //  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301 USA
 #include <stdarg.h>
 #include <stddef.h>
+#include <string.h>
 
 #include "rombios.h"
 
@@ -1197,7 +1198,12 @@
 {
     memcpy(h->signature, sig, 4);
     h->length = cpu_to_le32(len);
-    h->revision = 1;
+    // Desirable by Windows XP to support ACPI rev. 1.0b
+    if (strcmp(sig,"FACP") == 0) {
+        h->revision = 2;
+    }else{
+        h->revision = 1;
+    }
 #ifdef BX_QEMU
     memcpy(h->oem_id, "QEMU  ", 6);
     memcpy(h->oem_table_id, "QEMU", 4);
@@ -1306,9 +1312,8 @@
     fadt->pm1_evt_len = 4;
     fadt->pm1_cnt_len = 2;
     fadt->pm_tmr_len = 4;
-    fadt->plvl2_lat = cpu_to_le16(50);
-    fadt->plvl3_lat = cpu_to_le16(50);
-    fadt->plvl3_lat = cpu_to_le16(50);
+    fadt->plvl2_lat = cpu_to_le16(0x0fff); // C2 state not supported
+    fadt->plvl3_lat = cpu_to_le16(0x0fff); // C3 state not supported
     /* WBINVD + PROC_C1 + PWR_BUTTON + SLP_BUTTON + FIX_RTC */
     fadt->flags = cpu_to_le32((1 << 0) | (1 << 2) | (1 << 4) | (1 << 5) | (1 << 6));
     acpi_build_table_header((struct acpi_table_header *)fadt, "FACP", 

[-- Attachment #4: ATT3932870.txt --]
[-- Type: text/plain, Size: 319 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #5: ATT3932872.txt --]
[-- Type: text/plain, Size: 162 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests.
  2007-08-26  9:10 [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests Igor Lvovsky
@ 2007-08-26  9:51 ` Andreas Färber
  2007-08-27 16:22 ` Carlo Marcelo Arenas Belon
  1 sibling, 0 replies; 3+ messages in thread
From: Andreas Färber @ 2007-08-26  9:51 UTC (permalink / raw)
  To: qemu-devel

Hi,

Am 26.08.2007 um 11:10 schrieb Igor Lvovsky:
> >> Does anybody know what's going on? Is SMP support working at the  
> moment?
>
> >SMP works fine on Sparc32. Performance isn't great because the  
> CPUs are not halted in SMP mode but they busy loop when idle.
>
> I sent this patch before, but probably it was dropped.
>
> I hope it will help.

Possibly, but not for Sparc - that uses OpenBIOS instead of Bochs BIOS.

Andreas

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests.
  2007-08-26  9:10 [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests Igor Lvovsky
  2007-08-26  9:51 ` Andreas Färber
@ 2007-08-27 16:22 ` Carlo Marcelo Arenas Belon
  1 sibling, 0 replies; 3+ messages in thread
From: Carlo Marcelo Arenas Belon @ 2007-08-27 16:22 UTC (permalink / raw)
  To: qemu-devel

On Sun, Aug 26, 2007 at 02:10:01AM -0700, Igor Lvovsky wrote:
<SNIP>
>    As it was mentioned in forum (by Avi) it looks like the problem in the
>    windows Idle loop, that spinning instead of executing a 'hlt' instruction.

could you provide a reference to this thread?

>    So, the solution lies in ACPI area.  We need to modify a little bit ACPI
>    tables as following:

if windows is using an ACPI enabled HAL, but not it if it is using an MPS
enabled HAL like :

  halmps.dll (Multiprocessor PCs)

which you would get is using (-no-acpi) as explained below.

<SNIP>
>    Notes: The UP guest uses the HAL with the halaacpi.dll and windows Idle
>    loop work fine without ACPI support (I mean bios don't expose the CPU as
>    ACPI device).

if using -no-acpi then Windows will instead select the MPS HAL for UP instead
of the ACPI ones.

  hal.dll (Standard PCs)

if using ACPI then Windows will either use (dependent on the hardware support) :

  halacpi.dll (Advanced Configuration and Power Interface (ACPI) PCs)
  halapic.dll (Advanced Programmable Interrupt Controller (APIC) PCs)
  halaacpi.dll (APIC ACPI PCs)

in the case if Windows 2000 with your BIOS then it will use halaacpi.dll when
running qemu with ACPI enabled (without -no-acpi) and regardless of how many
processors are defined by -smp.

>    I attached the patch for BOCHS bios and compiled bios.bin.

this bios.bin is broken as it won't enable SMP even if ACPI is disabled (hence
using MPS) as can be seen if you try to start an SMP enabled Linux (like 
knoppix livecd).

I was able to reproduce the broken BIOS by applying the suggested (with some 
tweaks) patches to the current BOCHS CVS though and so it might be as well a
regression added since qemu's branch was created and compiled, but haven't yet
been able to dissect that bug as I am not sure either what version was used
originally for qemu's bios.bin

it does reduce the CPU consumption though, but it might be as well as a side 
effect of removing all contention between CPUs since there is only 1 anyway.

Carlo

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-08-27 16:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-26  9:10 [Qemu-devel] FW: [kvm-devel] CPU consumption for SMP windows guests Igor Lvovsky
2007-08-26  9:51 ` Andreas Färber
2007-08-27 16:22 ` Carlo Marcelo Arenas Belon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).