[Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Miroslav Novak]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

This patch adds support for slowing down qemu and saving cpu load.
The '-brake' command line parameter or monitor command 'brake' 
determines how long to wait in the main_loop with respect to duration of 
time that qemu used for the emulation itself.
Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11 
speed, etc.

A drawback of this approach is that the timer interrupt can be missed if 
raised too often. This happens if the loop_main divided by (1+brake) is 
less than the frequency of PIC interrupts.
In such case the time of emulated system runs slowly.

This problem occurs mainly for Linux emulation where kernel parameter HZ 
is of several hunderds.
For DOS emulation, where the timer interrupts are raised usualy at 18Hz, 
this approach works nice, and one can play old DOS games at reasonable 
speed and save batteries.


Mirek


[-- Attachment #2: brake.patch --]
[-- Type: text/x-patch, Size: 4905 bytes --]

diff -aur ../../orig/qemu-0.8.2/monitor.c ./monitor.c
--- ../../orig/qemu-0.8.2/monitor.c	2006-07-22 19:23:34.000000000 +0200
+++ ./monitor.c	2006-11-27 18:11:34.000000000 +0100
@@ -276,6 +276,14 @@
         term_printf("Invalid CPU index\n");
 }
 
+static void do_brake_set(int multiplier)
+{
+    if (multiplier < 0)
+        term_printf("Current brake multiplier %d\n", brake_mult);
+    else
+        brake_mult = multiplier;
+}
+
 static void do_info_jit(void)
 {
     dump_exec_info(NULL, monitor_fprintf);
@@ -1198,6 +1206,8 @@
 #endif
      { "stopcapture", "i", do_stop_capture,
        "capture index", "stop capture" },
+    { "brake", "i", do_brake_set, 
+      "multiplier", "set brake multiplier (non-negative integer), negative value prints actual setting" },
     { NULL, NULL, }, 
 };
 
diff -aur ../../orig/qemu-0.8.2/vl.c ./vl.c
--- ../../orig/qemu-0.8.2/vl.c	2006-07-22 19:23:34.000000000 +0200
+++ ./vl.c	2006-11-27 18:25:22.000000000 +0100
@@ -156,6 +156,7 @@
 #endif
 int acpi_enabled = 1;
 int fd_bootchk = 1;
+int brake_mult = 0;
 
 /***********************************************************/
 /* x86 ISA bus support */
@@ -5045,8 +5046,39 @@
 
 static CPUState *cur_cpu;
 
+
+int timeval_subtract(struct timeval *result, struct timeval *x, struct timeval *y) {
+	/* Perform the carry for the later subtraction by updating y. */
+	if (x->tv_usec < y->tv_usec) {
+		int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
+		y->tv_usec -= 1000000 * nsec;
+		y->tv_sec += nsec;
+	}
+	if (x->tv_usec - y->tv_usec > 1000000) {
+		int nsec = (x->tv_usec - y->tv_usec) / 1000000;
+		y->tv_usec += 1000000 * nsec;
+		y->tv_sec -= nsec;
+	}
+
+	/* Compute the time remaining to wait.
+	 *      tv_usec is certainly positive. */
+	result->tv_sec = x->tv_sec - y->tv_sec;
+	result->tv_usec = x->tv_usec - y->tv_usec;
+
+	/* Return 1 if result is negative. */
+	return x->tv_sec < y->tv_sec;
+}
+
+
 int main_loop(void)
 {
+    struct timeval tti, tti2, tti3, ttix;
+//#define BRAKE_DEBUG
+#ifdef BRAKE_DEBUG
+    int64_t mti, mti1, mti2, mti3;
+    int prcnt=0;
+#endif
+
     int ret, timeout;
 #ifdef CONFIG_PROFILER
     int64_t ti;
@@ -5055,6 +5087,11 @@
 
     cur_cpu = first_cpu;
     for(;;) {
+
+        gettimeofday(&tti, NULL);
+#ifdef BRAKE_DEBUG
+        mti = profile_getclock();
+#endif
         if (vm_running) {
 
             env = cur_cpu;
@@ -5113,6 +5150,41 @@
 #ifdef CONFIG_PROFILER
         dev_time += profile_getclock() - ti;
 #endif
+
+        gettimeofday(&tti2, NULL);
+#ifdef BRAKE_DEBUG
+        mti2 = profile_getclock();
+#endif
+
+        {
+            struct timespec ts;
+            int delus, delunc=0;
+            sigset_t sis, osis;
+
+            timeval_subtract(&ttix, &tti2, &tti);
+            delus = ttix.tv_usec*brake_mult - delunc;
+            ts.tv_sec=0;
+            ts.tv_nsec=delus*1000;
+
+            sigfillset(&sis);
+            sigprocmask(SIG_BLOCK, &sis, &osis);
+            if (delus>0) while (nanosleep(&ts, &ts));
+            sigprocmask(SIG_SETMASK, &osis, NULL);
+#ifdef BRAKE_DEBUG
+            mti3 = profile_getclock();
+#endif
+            gettimeofday(&tti3, NULL);
+
+            timeval_subtract(&ttix, &tti3, &tti2);
+            delunc = ttix.tv_usec-delus; 
+#ifdef BRAKE_DEBUG
+            if (!((++prcnt)%128)) {
+                printf("cycles %qd, \t%qd, \t%qd, \t%qd \%\n", (mti1 - mti), (mti2 - mti1), (mti3 - mti2), (100*(mti1 - mti))/(mti3-mti) );
+                //printf("del[us] %d, \t%d\n", delus, delunc);
+                //printf("ts[ns] = %d\n", ts.tv_nsec);
+            }
+#endif
+        }
     }
     cpu_disable_ticks();
     return ret;
@@ -5224,6 +5296,7 @@
 #endif
            "-loadvm file    start right away with a saved state (loadvm in monitor)\n"
 	   "-vnc display    start a VNC server on display\n"
+           "-brake multiplier    enables brake system which slows down qemu `multiplier'-times\n"
            "\n"
            "During emulation, the following keys are useful:\n"
            "ctrl-alt-f      toggle full screen\n"
@@ -5302,6 +5375,7 @@
     QEMU_OPTION_smp,
     QEMU_OPTION_vnc,
     QEMU_OPTION_no_acpi,
+    QEMU_OPTION_brake,
 };
 
 typedef struct QEMUOption {
@@ -5378,6 +5452,7 @@
     { "usb", 0, QEMU_OPTION_usb },
     { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
     { "no-acpi", 0, QEMU_OPTION_no_acpi },
+    { "brake", 1, QEMU_OPTION_brake },
     { NULL },
 };
 
@@ -6021,6 +6096,9 @@
             case QEMU_OPTION_no_acpi:
                 acpi_enabled = 0;
                 break;
+	    case QEMU_OPTION_brake:
+		brake_mult = atoi(optarg);
+		break;
             }
         }
     }
diff -aur ../../orig/qemu-0.8.2/vl.h ./vl.h
--- ../../orig/qemu-0.8.2/vl.h	2006-07-22 19:23:34.000000000 +0200
+++ ./vl.h	2006-11-27 18:09:41.000000000 +0100
@@ -1177,4 +1177,6 @@
 
 void kqemu_record_dump(void);
 
+extern int brake_mult;
+
 #endif /* VL_H */

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Martin Guy]

> This patch adds support for slowing down qemu and saving cpu load.

Poooooooooooooooo!

if you're using the right kernel, QEMU will sleep while there is
nothing to be done.
Otherwise just nice -10 it.

Voto contra

    M

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Martin Guy]

Then again, if someone needed it... it's not as if I have to use it...

    M

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Johannes Schindelin]

Hi,

On Fri, 1 Dec 2006, Martin Guy wrote:

> > This patch adds support for slowing down qemu and saving cpu load.
> 
> if you're using the right kernel, QEMU will sleep while there is
> nothing to be done.

As was stated by the OP, this is for DOS games. So, there is no "nothing 
to be done". Further, you are assuming everybody uses Linux. What makes 
you think so?

Besides, your "nice" would not do the same thing, you know? You'd need 
_another_ tast _using_ the CPU to slow down QEmu. Which would burn through 
the battery like hell.

Ciao,
Dscho

SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Martin Bochnig]

Johannes Schindelin wrote:

>>>This patch adds support for slowing down qemu and saving cpu load.
>>>      
>>>
>>if you're using the right kernel, QEMU will sleep while there is
>>nothing to be done.
>>    
>>
>
>As was stated by the OP, this is for DOS games. So, there is no "nothing 
>to be done". Further, you are assuming everybody uses Linux. What makes 
>you think so?
>
>Besides, your "nice" would not do the same thing, you know? You'd need 
>_another_ tast _using_ the CPU to slow down QEmu. Which would burn through 
>the battery like hell.
>
>Ciao,
>Dscho
>  
>

Might something like that help SoftICE for DOS16 to run properly without
freezing the whole guest after one or two ^D's  (i.e. for setting
breakpoints and switching back to the dos command.com)?
WinICE (on DOS386 a.k.a. {win386.exe / chicago's dos386.exe, now called
vmm32.vxd}) does/did already work well, when I last tested this a year
ago, but SoftICE for real mode DOS would always hang the whole guest
when being run inside QEMU (emulation case, not yet tested in case of
x86_x_x86 virtualization).
The same happens when using the Insignia_SoftWindows Pentium-ISA-PC
Emulator on Solaris_sparc, running any version of (MS-/IBM) or DRDOS.
Bochs claims to provide a more accurate emulation than qemu (at the cost
of making it marginally slower), but doesn't fix the SoftICE issue either.

It does - on the other hand - work as expected inside any version of
SunPCi, which only emulates a bit of io and graphics, but uses a
physical x86 cpu, rather than emulating it (I think it doesn't even have
to virtualize it, because nobody else is using the cpu sitting on that
pci card).

Has onybody found a way to work around the SoftICE_for_DOS16
instabilities under qemu?
(btw, my problems *are* qemu-dependant, not caused by an incompatible
himem.sys or anything of that sort / identical diskimages tested under
SunPCi, SoftWindows and qemu_for_SolarisSPARC-Hosts).

Thanks,
Maddin

Re: SoftICE under DOS16, anybody? __/__ Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Martin Bochnig]

Martin Bochnig wrote:

>>Might something like that help SoftICE for DOS16 to run properly without
>>freezing the whole guest after one or two ^D's  (i.e. for setting
>>breakpoints and switching back to the dos command.com)?
>>WinICE (on DOS386 a.k.a. {win386.exe / chicago's dos386.exe, now called
>>vmm32.vxd}) does/did already work well, when I last tested this a year
>>ago, but SoftICE for real mode DOS would always hang the whole guest
>>when being run inside QEMU (emulation case, not yet tested in case of
>>x86_x_x86 virtualization).
>>The same happens when using the Insignia_SoftWindows Pentium-ISA-PC
>>Emulator on Solaris_sparc, running any version of (MS-/IBM) or DRDOS.
>>Bochs claims to provide a more accurate emulation than qemu (at the cost
>>of making it marginally slower), but doesn't fix the SoftICE issue either.
>>
>>It does - on the other hand - work as expected inside any version of
>>SunPCi, which only emulates a bit of io and graphics, but uses a
>>physical x86 cpu, rather than emulating it (I think it doesn't even have
>>to virtualize it, because nobody else is using the cpu sitting on that
>>pci card).
>>
>>Has onybody found a way to work around the SoftICE_for_DOS16
>>instabilities under qemu?
>>(btw, my problems *are* qemu-dependant, not caused by an incompatible
>>himem.sys or anything of that sort / identical diskimages tested under
>>SunPCi, SoftWindows and qemu_for_SolarisSPARC-Hosts).
>>
>>Thanks,
>>Maddin
>>    
>>


I might some remote day invest a bit of effort into trying to find out
WHY exactly SoftICE_for_realmodeDOS hangs the emulation (under qemu,
bochs and SoftWindows/RealPC) :
Whether or not it freezes "somehow internally" because of  "actually
running", or, more specifically, whether it just has to do with
listening to the keyboard for "^D" sequences (int16h and int21h_AH==01 /
see Ralf Brown's grand Interrupt list) to activate the SoftICE UI.
If it is "just" the latter, then maybe due to a timing related problem,
or maybe because the SoftICE-TSR somehow interferes with COMMAND.COM (or
any shell like i.e. BASH_for_DOS or 4DOS.COM) that are concurrently
listening to kbd input and therefore actively issuing certains DOS-21h
and 16h interrupts permanently (with appropriate values in (E)AL, (E)AL,
or(E)AX, permanently requesting the keyboard, if it has new input in its
associated stdin buffer (not quite correct, simplified).

The issue applies to all major SoftICE_for_realmodeDOS releases/versions.

Thanks.

--
Martin

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Miroslav Novak]

I'm sending some more facts that should make clear why I think the 
functionality provided by the patch is relevant. (At least for the DOS 
emulation.)

Making emulated CPU slower
  Some old DOS games runs too fast on modern CPUs, even the qemu-emulted
ones. This patch can make these games playable.
  This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1264

Energy saving
  MSDOS doesn't use HLT insn. Even if the dosidle can help in command 
prompt, it doesn't work in other programs such as games.
  This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1372

The similar approach is used in dosbox by setting "CPU cycles". I think 
qemu is better than dosbox, so it makes sense to me to include such 
capability too. 

This patch doesn't try to emulate the task scheduler that was why Martin 
voted against it. I'm sorry if I wasnt't clear enough in my first post.

Mirek.



On Thu, 30 Nov 2006, Miroslav Novak wrote:

> This patch adds support for slowing down qemu and saving cpu load.
> The '-brake' command line parameter or monitor command 'brake' determines how
> long to wait in the main_loop with respect to duration of time that qemu used
> for the emulation itself.
> Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11 speed,
> etc.
> 
> A drawback of this approach is that the timer interrupt can be missed if
> raised too often. This happens if the loop_main divided by (1+brake) is less
> than the frequency of PIC interrupts.
> In such case the time of emulated system runs slowly.
> 
> This problem occurs mainly for Linux emulation where kernel parameter HZ is of
> several hunderds.
> For DOS emulation, where the timer interrupts are raised usualy at 18Hz, this
> approach works nice, and one can play old DOS games at reasonable speed and
> save batteries.
> 
> 
> Mirek
> 
> 

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Miroslav Novak]

I'm sending some more facts that should make clear why I think the
functionality provided by the patch is relevant. (At least for the DOS
emulation.)

Making emulated CPU slower
  Some old DOS games runs too fast on modern CPUs, even the qemu-emulted
ones. This patch can make these games playable.
  The problem was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1264

Energy saving
  MSDOS doesn't use HLT insn. Even if the dosidle can help in command
prompt, it doesn't work in other programs such as games.
  This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1372

The similar approach is used in dosbox by setting "CPU cycles". I think
qemu is better than dosbox, so it makes sense to me to include such
capability too.

This patch doesn't try to emulate the task scheduler that was why Martin
voted against it. I'm sorry if I wasnt't clear enough in my first post.

Mirek.



On Thu, 30 Nov 2006, Miroslav Novak wrote:

> This patch adds support for slowing down qemu and saving cpu load.
> The '-brake' command line parameter or monitor command 'brake' determines how
> long to wait in the main_loop with respect to duration of time that qemu used
> for the emulation itself.
> Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11 speed,
> etc.
> 
> A drawback of this approach is that the timer interrupt can be missed if
> raised too often. This happens if the loop_main divided by (1+brake) is less
> than the frequency of PIC interrupts.
> In such case the time of emulated system runs slowly.
> 
> This problem occurs mainly for Linux emulation where kernel parameter HZ is of
> several hunderds.
> For DOS emulation, where the timer interrupts are raised usualy at 18Hz, this
> approach works nice, and one can play old DOS games at reasonable speed and
> save batteries.
> 
> 
> Mirek
> 
> 

Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Manish Gajbhiye]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

Hi,


We are faceing one Problem in Qemu guest os winxp . The Qemu hbas been
installed in Linux CentOs 4.4 . Guest os detected the Realtek Lan Adapter .
BUt with is Adpeter we are unable  get the IP from Our Dhcp Server. Could
you suggest how to do this.

Regards
Manish


On 12/6/06, Miroslav Novak <mira@kmlinux.fjfi.cvut.cz> wrote:
>
>
>
> I'm sending some more facts that should make clear why I think the
> functionality provided by the patch is relevant. (At least for the DOS
> emulation.)
>
> Making emulated CPU slower
>   Some old DOS games runs too fast on modern CPUs, even the qemu-emulted
> ones. This patch can make these games playable.
>   The problem was reported in
> http://qemu-forum.ipi.fi/viewtopic.php?t=1264
>
> Energy saving
>   MSDOS doesn't use HLT insn. Even if the dosidle can help in command
> prompt, it doesn't work in other programs such as games.
>   This was reported in http://qemu-forum.ipi.fi/viewtopic.php?t=1372
>
> The similar approach is used in dosbox by setting "CPU cycles". I think
> qemu is better than dosbox, so it makes sense to me to include such
> capability too.
>
> This patch doesn't try to emulate the task scheduler that was why Martin
> voted against it. I'm sorry if I wasnt't clear enough in my first post.
>
> Mirek.
>
>
>
> On Thu, 30 Nov 2006, Miroslav Novak wrote:
>
> > This patch adds support for slowing down qemu and saving cpu load.
> > The '-brake' command line parameter or monitor command 'brake'
> determines how
> > long to wait in the main_loop with respect to duration of time that qemu
> used
> > for the emulation itself.
> > Thus e.g. zero value runs at full speed, 1 at 1/2 speed, 10 at 1/11
> speed,
> > etc.
> >
> > A drawback of this approach is that the timer interrupt can be missed if
> > raised too often. This happens if the loop_main divided by (1+brake) is
> less
> > than the frequency of PIC interrupts.
> > In such case the time of emulated system runs slowly.
> >
> > This problem occurs mainly for Linux emulation where kernel parameter HZ
> is of
> > several hunderds.
> > For DOS emulation, where the timer interrupts are raised usualy at 18Hz,
> this
> > approach works nice, and one can play old DOS games at reasonable speed
> and
> > save batteries.
> >
> >
> > Mirek
> >
> >
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

[-- Attachment #2: Type: text/html, Size: 3152 bytes --]

Network problem, was Re: [Qemu-devel] [PATCH] intentinoal slowing down qemu - brake

[Johannes Schindelin]

Hi,

please do not reply to something completely unrelated.

On Wed, 6 Dec 2006, Manish Gajbhiye wrote:

> We are faceing one Problem in Qemu guest os winxp . The Qemu hbas been 
> installed in Linux CentOs 4.4 . Guest os detected the Realtek Lan 
> Adapter . BUt with is Adpeter we are unable get the IP from Our Dhcp 
> Server.

The network card QEmu detects is a _virtual_ one. And it should already 
have received an IP by the _virtual_ DHCP in QEmu. The _virtual_ router 
inside QEmu will act as a masquerading firewall to your QEmu instance, so 
that network connections to the wide world will seem to originate from 
your _host_ machine.

Hth,
Dscho