[Qemu-devel] Qemu workstation

[Qemu-devel] Qemu workstation

[Jean-Michel POURE]

Dear all,

Just a quick note to inform that according to the wiki 
(http://am.xs4all.nl/phpwiki/index.php/Qemu),
some work is being done to produce frontends to Qemu:

Win32         --> http://www.revenitor.co.uk/qews.asp
GNU/Linux --> http://am.xs4all.nl/phpwiki/index.php/QemuWorkstation

Cheers, Jean-Michel

Re: [Qemu-devel] Qemu workstation

[John R. Hogerhuis]

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

Sweet Jesus... a new name, vmware shell look alike (not a step in the
right direction IMHO... we could probably come up with a better UI than
to rehash vmware's...) and the win32 port is not really operational yet
(unless 0.5.3 actually made it process .iso files... I haven't built
yet...)

Well I guess there's something to be said for multi-tasking.

Does anyone know who this is? I'd like to find out what kind of magic
they are performing to get ReactOS running in win32 port.

Alas I suspect GIMP at work...

-- John.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Qemu workstation

[Rudi Lippert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i agree. i don't know anything about the windows port, but personally, i think 
the draft of the linux-frontend looks more functional.
one thing about multitasking: there should probably be an option in the 
preferences dialog allowing to STOP the vm as soon as the focus goes to 
another one and to CONT that one. that would definitely be a step ahead of 
vmware, since they don't allow stopping a vm without dumping the memory to 
the hd.
it is probably too early to talk about these things, but it came to my mind 
today, so why not post it today.
another question: are there sources available for the linux frontend? many 
people on this list will also test the frontend, which would certainly speed 
up its development.
€0.06

"Re: [Qemu-devel] Qemu workstation" (John R. Hogerhuis, Monday 05 April 2004 
11:10):
> Sweet Jesus... a new name, vmware shell look alike (not a step in the
> right direction IMHO... we could probably come up with a better UI than
> to rehash vmware's...) and the win32 port is not really operational yet
> (unless 0.5.3 actually made it process .iso files... I haven't built
> yet...)
>
> Well I guess there's something to be said for multi-tasking.
>
> Does anyone know who this is? I'd like to find out what kind of magic
> they are performing to get ReactOS running in win32 port.
>
> Alas I suspect GIMP at work...
>
> -- John.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAcScc1nTg39QS/TsRAt72AJ4wGaL9c/iwA+a7R8dL5qznUZVf7ACeJtDs
v4GGCxmFBog9WbCrmLO7DHg=
=mdod
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Qemu workstation

[Jean-Michel POURE]

Le lundi 5 Avril 2004 11:30, Rudi Lippert a écrit :
> another question: are there sources available for the linux frontend? many
> people on this list will also test the frontend, which would certainly
> speed up its development.
> €0.06

Dear Rudi,

I contacted Alex on Morphix mailing list about this issue. My post is:
http://www.morphix.org/modules/newbb/viewtopic.php?topic_id=1239&forum=3&jump=1

Cheers,
Jean-Michel

Re: [Qemu-devel] Qemu workstation

[Fabrice Bellard]

Hi,

I am interested by a GTK GUI for QEMU and I think it should be commited 
in the main QEMU CVS.

Some notes about the GUI:

- Avoid using SDL or SDL wrappers: it is simpler to use plain GTK or GDK 
to draw the VGA frame buffer.

- I am not sure that handling multiple VMs running at the same time is 
very useful (some architectural changes are needed in QEMU). But 
switching easily between VM configurations seems interesting.

- The VM description management must be integrated in the QEMU core. I 
plan to work on it soon (Renzo Davoli sent patch I need to study).

- The VM console should be available in a separate TAB for the hackers !

- Of course there should be commands to eject/insert medias, to change 
the hard disk images and to update the VM configuration (ideally a 
simple dialog for dummies and a more technical one to change IRQs, IO 
ports, number of interfaces).

Fabrice.

Jean-Michel POURE wrote:
> Le lundi 5 Avril 2004 11:30, Rudi Lippert a écrit :
> 
>>another question: are there sources available for the linux frontend? many
>>people on this list will also test the frontend, which would certainly
>>speed up its development.
>>€0.06
> 
> 
> Dear Rudi,
> 
> I contacted Alex on Morphix mailing list about this issue. My post is:
> http://www.morphix.org/modules/newbb/viewtopic.php?topic_id=1239&forum=3&jump=1
> 
> Cheers,
> Jean-Michel
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Qemu workstation

[Jamie Burns]

> I am not sure that handling multiple VMs running at the same time is
> very useful (some architectural changes are needed in QEMU). But
> switching easily between VM configurations seems interesting.

I think that multiple VM's is a worthy goal as long as you can minimise CPU
usage. Having multiple VM's gives you the ability to do some very cool
things. I use VMWARE in Windows and sometimes have both Linux and FreeBSD
running in VM's so I can test software against all 3 OS's at once. I imagine
it would be very useful to developers of cluster software.

I tried the Win32 port the other day, running Linux, and it sat using 100%
of the CPU whilst doing next to nothing at a command prompt. Using VMWARE,
and waiting at a command prompt uses very little CPU time.

Is QEMU sat in a busy loop all the time?

Jamie.

Re: [Qemu-devel] Qemu workstation

[Richard Zidlicky]

On Mon, Apr 05, 2004 at 10:49:51PM +0100, Jamie Burns wrote:
> > I am not sure that handling multiple VMs running at the same time is
> > very useful (some architectural changes are needed in QEMU). But
> > switching easily between VM configurations seems interesting.
> 
> I think that multiple VM's is a worthy goal as long as you can minimise CPU
> usage. Having multiple VM's gives you the ability to do some very cool
> things. I use VMWARE in Windows and sometimes have both Linux and FreeBSD
> running in VM's so I can test software against all 3 OS's at once. I imagine
> it would be very useful to developers of cluster software.
> 
> I tried the Win32 port the other day, running Linux, and it sat using 100%
> of the CPU whilst doing next to nothing at a command prompt. Using VMWARE,
> and waiting at a command prompt uses very little CPU time.
> 
> Is QEMU sat in a busy loop all the time?

it is not QEMU but the hosted OS that is in the busy loop. QEMU
will have to recognise "idle loops" to fix this - this could be
really tricky.

Richard

Re: [Qemu-devel] Qemu workstation

[Brad Campbell]

Richard Zidlicky wrote:
> On Mon, Apr 05, 2004 at 10:49:51PM +0100, Jamie Burns wrote:
> 
>>>I am not sure that handling multiple VMs running at the same time is
>>>very useful (some architectural changes are needed in QEMU). But
>>>switching easily between VM configurations seems interesting.
>>
>>I think that multiple VM's is a worthy goal as long as you can minimise CPU
>>usage. Having multiple VM's gives you the ability to do some very cool
>>things. I use VMWARE in Windows and sometimes have both Linux and FreeBSD
>>running in VM's so I can test software against all 3 OS's at once. I imagine
>>it would be very useful to developers of cluster software.
>>
>>I tried the Win32 port the other day, running Linux, and it sat using 100%
>>of the CPU whilst doing next to nothing at a command prompt. Using VMWARE,
>>and waiting at a command prompt uses very little CPU time.
>>
>>Is QEMU sat in a busy loop all the time?
> 
> 
> it is not QEMU but the hosted OS that is in the busy loop. QEMU
> will have to recognise "idle loops" to fix this - this could be
> really tricky.

I guess if QEMU emulates the hlt instruction and the OS supports it then it's pretty easy.
I note above it said running linux, which does idle nicely when the hlt instruction is present, 
perhaps there is a not too difficult way for intelligent OS's. DOS is a lost cause however.

Brad

Re: [Qemu-devel] Qemu workstation

[Filip Navara]

Brad Campbell wrote:

> I guess if QEMU emulates the hlt instruction and the OS supports it 
> then it's pretty easy.
> I note above it said running linux, which does idle nicely when the 
> hlt instruction is present, perhaps there is a not too difficult way 
> for intelligent OS's. DOS is a lost cause however.

To clarify it, it's not 'HLT' instruction (Halt processor), but the 
'NOP' instruction (No operation).

- Filip

Re: [Qemu-devel] Qemu workstation

[Brad Campbell]

Filip Navara wrote:
> Brad Campbell wrote:
> 
>> I guess if QEMU emulates the hlt instruction and the OS supports it 
>> then it's pretty easy.
>> I note above it said running linux, which does idle nicely when the 
>> hlt instruction is present, perhaps there is a not too difficult way 
>> for intelligent OS's. DOS is a lost cause however.
> 
> 
> To clarify it, it's not 'HLT' instruction (Halt processor), but the 
> 'NOP' instruction (No operation).

How does that work then?
I have some code that uses a NOP loop for accurate timing? That spins at 100% cpu usage, how does a 
NOP tell the processor to idle? HLT does.

Brad

Re: [Qemu-devel] Qemu workstation

[Filip Navara]

Brad Campbell wrote:
> How does that work then?

I don't know the exact details.

> I have some code that uses a NOP loop for accurate
> timing? That spins at 100% cpu usage, how does a 
> NOP tell the processor to idle? HLT does.

HLT instruction halts the CPU so no more instructions are
processed and the CPU freezes. That's usable only in situation
like Windows blue screens.

- Filip

-- 
ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned!
Pripojeni na cisle 971 200 111 z cele CR,
v Praze navic na cisle 971 200 555.
Uzivatelske jmeno "volny", heslo "volny".
http://sluzby.volny.cz/product/dialup/anon/

Re: [Qemu-devel] Qemu workstation

[Brad Campbell]

Filip Navara wrote:
> Brad Campbell wrote:
> 
>>How does that work then?
> 
> 
> I don't know the exact details.
> 
> 
>>I have some code that uses a NOP loop for accurate
>>timing? That spins at 100% cpu usage, how does a 
>>NOP tell the processor to idle? HLT does.
> 
> 
> HLT instruction halts the CPU so no more instructions are
> processed and the CPU freezes. That's usable only in situation
> like Windows blue screens.

It does? My information tells me that it halts the processor until an interrupt or other wakeup 
source occurs. Check arch/i386/kernel/process.c

/*
  * We use this if we don't have any better
  * idle routine..
  */
void default_idle(void)
{
         if (current_cpu_data.hlt_works_ok && !hlt_counter) {
                 __cli();
                 if (!current->need_resched)
                         safe_halt();
                 else
                         __sti();
         }
}

and in include/asm/system.h

system.h:#define safe_halt()            __asm__ __volatile__("sti; hlt": : :"memory")

Looks like a hlt to me and not a nop in site.
The kernel does a check at boot time to see if the processor supports the hlt instruction and if it 
does it uses that in the idle loop.

Am I wrong?

Brad

Re: [Qemu-devel] Qemu workstation

[Grzegorz Kulewski]

On Wed, 7 Apr 2004, Brad Campbell wrote:

> Filip Navara wrote:
> > Brad Campbell wrote:
> > 
> >>How does that work then?
> > 
> > 
> > I don't know the exact details.
> > 
> > 
> >>I have some code that uses a NOP loop for accurate
> >>timing? That spins at 100% cpu usage, how does a 
> >>NOP tell the processor to idle? HLT does.
> > 
> > 
> > HLT instruction halts the CPU so no more instructions are
> > processed and the CPU freezes. That's usable only in situation
> > like Windows blue screens.
> 
> It does? My information tells me that it halts the processor until an interrupt or other wakeup 
> source occurs. Check arch/i386/kernel/process.c
> 
> /*
>   * We use this if we don't have any better
>   * idle routine..
>   */
> void default_idle(void)
> {
>          if (current_cpu_data.hlt_works_ok && !hlt_counter) {
>                  __cli();
>                  if (!current->need_resched)
>                          safe_halt();
>                  else
>                          __sti();
>          }
> }
> 
> and in include/asm/system.h
> 
> system.h:#define safe_halt()            __asm__ __volatile__("sti; hlt": : :"memory")
> 
> Looks like a hlt to me and not a nop in site.
> The kernel does a check at boot time to see if the processor supports the hlt instruction and if it 
> does it uses that in the idle loop.
> 
> Am I wrong?

You are right.

HLT will block only until interrupt arrives. And there is at least clock 
interrupt from time to time.

It helps to cool down the processor too. And autodetection on some 
processors / motherboards is not correct, so there is nohalt kernel 
parameter.

For blue screens (for me red since I use some tweaker :-) - *no more blue 
screens*(TM)) win probably uses JMP $ or something like that (depending on 
their/your assembler syntax).

And NOP instruction is not good candidate for wasting time anymore on 
newer processrs (since PII I think, maybe later) since processor can 
optimize it out and the only thing that survives that optimization is 
conditional jump, but in cache, so latency is very small.


regards

Grzegorz Kulewski

Re: [Qemu-devel] Qemu workstation

[Richard Zidlicky]

On Wed, Apr 07, 2004 at 10:47:26AM +0200, Grzegorz Kulewski wrote:
> On Wed, 7 Apr 2004, Brad Campbell wrote:
> 
> > Filip Navara wrote:
> > > Brad Campbell wrote:
> > > 
> > >>How does that work then?
> > > 
> > > 
> > > I don't know the exact details.
> > > 
> > > 
> > >>I have some code that uses a NOP loop for accurate
> > >>timing? That spins at 100% cpu usage, how does a 
> > >>NOP tell the processor to idle? HLT does.
> > > 
> > > 
> > > HLT instruction halts the CPU so no more instructions are
> > > processed and the CPU freezes. That's usable only in situation
> > > like Windows blue screens.
> > 
> > It does? My information tells me that it halts the processor until an interrupt or other wakeup 
> > source occurs. Check arch/i386/kernel/process.c
> > 
> > /*
> >   * We use this if we don't have any better
> >   * idle routine..
> >   */
> > void default_idle(void)
> > {
> >          if (current_cpu_data.hlt_works_ok && !hlt_counter) {
> >                  __cli();
> >                  if (!current->need_resched)
> >                          safe_halt();
> >                  else
> >                          __sti();
> >          }
> > }
> > 
> > and in include/asm/system.h
> > 
> > system.h:#define safe_halt()            __asm__ __volatile__("sti; hlt": : :"memory")
> > 
> > Looks like a hlt to me and not a nop in site.
> > The kernel does a check at boot time to see if the processor supports the hlt instruction and if it 
> > does it uses that in the idle loop.
> > 
> > Am I wrong?
> 
> You are right.
> 
> HLT will block only until interrupt arrives. And there is at least clock 
> interrupt from time to time.

.. anyone remembers the Pentium(tm) "halt" bug ? How should QEMU
emulate that ?;)

it is easy when the guest OS uses hlt of course but a brief look
at some Linux kernel sources suggests there are a few more methods
to do it. Well x86 assembly was never my strong point.

Richard

Re: [Qemu-devel] Qemu workstation

[Filip Navara]

----- PŮVODNÍ ZPRÁVA -----
Od: "Brad Campbell" <brad@wasp.net.au>
Komu: qemu-devel@nongnu.org
Předmět: Re: [Qemu-devel] Qemu workstation
Datum: 7.4.2004 - 10:24:12

...
 
> It does? My information tells me that it halts the
> processor until an interrupt or other wakeup 
> source occurs. Check arch/i386/kernel/process.c
> 
> /*
> * We use this if we don't have any better
> * idle routine..
> */
> void default_idle(void)
> {
> if (current_cpu_data.hlt_works_ok && !hlt_counter) {
> __cli();
> if (!current->need_resched)
> safe_halt();
> else
> __sti();
> }
> }
> 
> and in include/asm/system.h
> 
> system.h:#define safe_halt()            __asm__
> __volatile__("sti; hlt": : :"memory")
> 
> Looks like a hlt to me and not a nop in site.
> The kernel does a check at boot time to see if the
> processor supports the hlt instruction and if it 
> does it uses that in the idle loop.
> 
> Am I wrong?
> 
> Brad
> 

You are right and I'm wrong, sorry.

- Filip


-- 
ANONYMNI PRIPOJENI K INTERNETU - bez registrace, zdarma, ihned!
Pripojeni na cisle 971 200 111 z cele CR,
v Praze navic na cisle 971 200 555.
Uzivatelske jmeno "volny", heslo "volny".
http://sluzby.volny.cz/product/dialup/anon/

Re: [Qemu-devel] Qemu workstation

[Jamie Burns]

Isnt there an instruction that gets sent when the OS is idle? To keep
processors cool etc?

VMWare describes some of this in:

http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1077

:o)


----- Original Message ----- 
From: "Richard Zidlicky" <rz@linux-m68k.org>
To: <qemu-devel@nongnu.org>
Sent: Tuesday, April 06, 2004 1:17 PM
Subject: Re: [Qemu-devel] Qemu workstation


> On Mon, Apr 05, 2004 at 10:49:51PM +0100, Jamie Burns wrote:
> > > I am not sure that handling multiple VMs running at the same time is
> > > very useful (some architectural changes are needed in QEMU). But
> > > switching easily between VM configurations seems interesting.
> >
> > I think that multiple VM's is a worthy goal as long as you can minimise
CPU
> > usage. Having multiple VM's gives you the ability to do some very cool
> > things. I use VMWARE in Windows and sometimes have both Linux and
FreeBSD
> > running in VM's so I can test software against all 3 OS's at once. I
imagine
> > it would be very useful to developers of cluster software.
> >
> > I tried the Win32 port the other day, running Linux, and it sat using
100%
> > of the CPU whilst doing next to nothing at a command prompt. Using
VMWARE,
> > and waiting at a command prompt uses very little CPU time.
> >
> > Is QEMU sat in a busy loop all the time?
>
> it is not QEMU but the hosted OS that is in the busy loop. QEMU
> will have to recognise "idle loops" to fix this - this could be
> really tricky.
>
> Richard
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu workstation

[Fabrice Bellard]

Jamie Burns wrote:

> Is QEMU sat in a busy loop all the time?

No. It comes from the Windows port. I'll make a simple patch soon.

Fabrice.

Re: [Qemu-devel] Qemu workstation

[Jean-Michel POURE]

Dear all,

> Sweet Jesus... a new name, vmware shell look alike (not a step in the
> right direction IMHO... we could probably come up with a better UI than
> to rehash vmware's...) and the win32 port is not really operational yet
> (unless 0.5.3 actually made it process .iso files... I haven't built
> yet...)

Unless further evidence, source-code of QEWS for Win32 is not made available.

> Well I guess there's something to be said for multi-tasking.
> Does anyone know who this is? I'd like to find out what kind of magic
> they are performing to get ReactOS running in win32 port.
> Alas I suspect GIMP at work...

Do you mean this project might be a hoax?

On the other hand, I would very like appreciate Alex (from the Morphix 
project) to commit his GNU/Linux code to Qemu CVS. It would probably be 
time/energy saving to build the GUI from Qemu CVS.

Cheers,
Jean-Michel

Re: [Qemu-devel] Qemu workstation

[John R. Hogerhuis]

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

On Mon, 2004-04-05 at 02:38, Jean-Michel POURE wrote:
> Do you mean this project might be a hoax?

I definitely wouldn't go that far. Haven't looked into it enough to say
anything like that.

More like saying the Win32 version is probably vaporware (i.e.
implementation not complete, with initial mock-up of running system for
marketing purposes).

Has anyone gotten ReactOS to run in QEMU on Win32? The only one I know
could have gotten that far is Mike. Otherwise, one would have to posit
the existance of yet another win32 port of qemu.

-- John.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Qemu workstation

[Mike Nordell]

Browsing the archives I spotted something I wanted to comment on.

John R. Hogerhuis wrote:

> More like saying the Win32 version is probably vaporware (i.e.
> implementation not complete, with initial mock-up of running
> system for marketing purposes).

As I've talked to a person on IRC presenting itself as the author, the
information I got was that the thing at the .co.uk site is a Visual Basic
application that works by hijacking the SDL window from the QEMU process and
displaying it as if it was its own output.

Possibly that's where the 733MHz CPU and 500MB free harddisk space
requirments (http://www.revenitor.co.uk/qews.asp) might be from...


As for running ReactOS under QEMU (on Win32); yes, I have run it.


/Mike

Re: [Qemu-devel] Qemu workstation

[Filip Navara]

Mike Nordell wrote:

>As for running ReactOS under QEMU (on Win32); yes, I have run it.
>  
>
+1

I'm running it inside QEMU everyday.

- Filip

Re: [Qemu-devel] Qemu workstation

[John R. Hogerhuis]

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

Okay first it seems I was largely wrong about this shell... it seems
that although it is not complete it is not vaporware (apologies to Alex)

Filip, are you running the windows port from CVS? Or are you running
ReactOS from QEMU under Linux?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Qemu workstation

[Filip Navara]

John R. Hogerhuis wrote:

>Filip, are you running the windows port from CVS? Or are you running
>ReactOS from QEMU under Linux?
>  
>
I'm running the Windows port from CVS with some local fixes (i think 
most of then appered on the mailing list already) and I also the tried 
the port made by Mike Nordell with similar results.

- Filip