John R. Hogerhuis | 1 Oct 01:55 2004
Picon

QEMU feature idea: simple macros/scripting

I have a suggestion for a feature for QEMU:

Macros/Scripting. For the most part, on my machines Windows is a very
manual labor intensive peripheral. I haven't moved to an open source
accounting package yet, so I use Quickbooks. I use it to keep track of
invoices and consulting hours. But every time I print an invoice between
evolution and the virtual machine, copy name/address information between
the two systems and print an invoice to file, ftp that file back over to
Linux, convert it to pdf, and mail to my customer.

I think if Windows under QEMU were scriptable, that I could take several
steps out of my workflow (I imagine there are other ways I could
automate it as well).

So I think the FTP server addition for exchanging files, in concert with
some way to actually record/playback typing at the keyboard and clicking
the mouse would allow me to use Windows as a peripheral.

Similarly for Windows only hardware (no Linux driver), one could utilize
such a Mother of All Kludges.

This would also be a real boon to testers since they could easily script
out clicks and keypresses (so long as they can figure out a way to
record "evidence" of a successful test... file showing up on disk, or
maybe you allow screen captures at key points to be added to the script
and viewed by a person to determine if the test was successful).

You would probably want a way to stretch and shrink the amount of time
it takes to run different parts of the script, since just playing back
often won't work, but sometimes it does.
(Continue reading)

Johannes Schindelin | 1 Oct 02:19 2004
Picon
Picon

Re: QEMU feature idea: simple macros/scripting

Hi,

On Thu, 30 Sep 2004, John R. Hogerhuis wrote:

> Macros/Scripting. For the most part, on my machines Windows is a very
> manual labor intensive peripheral.

I started to write a vnc frontend for QEmu. On the other end, I started to
write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
but also Macros/Scripting for everything which can be controlled by a
vncviewer. For now, I use an adaption of vncrec, which just records inputs
and timestamps, and play those inputs back later.

Ciao,
Dscho
John R. Hogerhuis | 1 Oct 05:40 2004
Picon

Re: QEMU feature idea: simple macros/scripting

On Thu, 2004-09-30 at 17:19, Johannes Schindelin wrote:

> I started to write a vnc frontend for QEmu. On the other end, I started to
> write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> but also Macros/Scripting for everything which can be controlled by a
> vncviewer. For now, I use an adaption of vncrec, which just records inputs
> and timestamps, and play those inputs back later.

Sounds like your solution would work for me as well. I hadn't thought of
using vnc and related tools.

I'm not sure what kind of integration makes sense, if any.

A record/playback feature could be

1) In QEMU proper wedged between the QEMU and the guest, hooked into the
data traffic
2) In a front end to QEMU which just communicates through a
to-be-implemented API; basically still #1 just architecturally different
3) In a completely separate utility that knows nothing about QEMU and
just deals with X. Such utilities exist for X
4) In a VNC viewer
5) In the guest only; such utilities exist for Windows and probably some
other OSes.

Not sure what the pros/cons are exactly. (5) can be ruled out since you
wouldn't be able to script at the QEMU level (saving/loading system
state images and such, and not all OSes necessarily have good utilities
for recording and playing back such events.

(Continue reading)

Lionel Ulmer | 1 Oct 09:09 2004
Picon

Re: QEMU feature idea: simple macros/scripting

On Fri, Oct 01, 2004 at 02:19:39AM +0200, Johannes Schindelin wrote:
> > Macros/Scripting. For the most part, on my machines Windows is a very
> > manual labor intensive peripheral.
> 
> I started to write a vnc frontend for QEmu. On the other end, I started to
> write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> but also Macros/Scripting for everything which can be controlled by a
> vncviewer. For now, I use an adaption of vncrec, which just records inputs
> and timestamps, and play those inputs back later.

What could also be investigated is the 'regression' tool supposedly written
by CodeWeavers for Wine (I never played with it so I do not know the current
status - i.e. freely distributable or not) but it looks similar to what you
want to do: automatic button presses on dialog buttons, checking of results,
...

The problem is that I have no idea if it works at a pure 'bitmap' level or
if it needs to have knowledge of the window hierarchy and stuff like that
(i.e. hooks into Win32 or X11 via some API calls).

     Lionel

--

-- 
		 Lionel Ulmer - http://www.bbrox.org/
Christian Wiese | 1 Oct 10:14 2004
Picon
Picon

Re: BeOS/Zeta eats 100% cpu time

André Braga wrote:

>SDL might not be handling this intelligently, or maybe it's the
>graphics emulation or the Cirrus BIOS; anyway, QEMU goes idle when I
>boot a console-mode OS, and goes for 100% CPU when I boot any
>graphical OS, BeOS included.
>  
>
Don´t think so, because if I run ReactOS in VESA mode, qEmu won´t use 
100% of the host CPU. So there must be something else, which causes this 
huge overhead.
Maybe I find some time to build an profiling-enabled version.

Greetings,
 Chris
Johannes Schindelin | 1 Oct 11:54 2004
Picon
Picon

Re: QEMU feature idea: simple macros/scripting

Hi,

On Thu, 30 Sep 2004, John R. Hogerhuis wrote:

> On Thu, 2004-09-30 at 17:19, Johannes Schindelin wrote:
>
> > I started to write a vnc frontend for QEmu. On the other end, I started to
> > write a scriptable vnc viewer. The use of this? Macros/Scripting for QEmu,
> > but also Macros/Scripting for everything which can be controlled by a
> > vncviewer. For now, I use an adaption of vncrec, which just records inputs
> > and timestamps, and play those inputs back later.
>
> Sounds like your solution would work for me as well. I hadn't thought of
> using vnc and related tools.
>
> I'm not sure what kind of integration makes sense, if any.
>
> A record/playback feature could be
>
> 1) In QEMU proper wedged between the QEMU and the guest, hooked into the
> data traffic

You would probably not even need that much, but just write your own
frontend (see vnc.c, or no-sdl hack for examples). Maybe a scriptable
frontend via SWIG; the main application loop would probably have to run in
an own thread.

> 2) In a front end to QEMU which just communicates through a
> to-be-implemented API; basically still #1 just architecturally different

(Continue reading)

Johannes Schindelin | 1 Oct 12:08 2004
Picon
Picon

Re: QEMU feature idea: simple macros/scripting

Hi,

On Fri, 1 Oct 2004, Lionel Ulmer wrote:

> What could also be investigated is the 'regression' tool supposedly written
> by CodeWeavers for Wine (I never played with it so I do not know the current
> status - i.e. freely distributable or not) but it looks similar to what you
> want to do: automatic button presses on dialog buttons, checking of results,
> ...

I was not able to find the tool on the net, but rumours tell that it works
on the Win32 API level.

Ciao,
Dscho
Johannes Schindelin | 1 Oct 14:56 2004
Picon
Picon

ne2000 savevm patch, 2nd try

Hi,

I restructured my patch (minimal changes only). Now, only ne2000 (in pci
mode) and piix3 register savevm functions. I just confirmed that Win98
with user net keeps working after loadvm'ing with this patch.

Ciao,
Dscho
diff -Nurb qemu_cvs/hw/ne2000.c qemu__ne2000_savevm/hw/ne2000.c
--- qemu_cvs/hw/ne2000.c	2004-10-01 14:50:48.000000000 +0200
+++ qemu__ne2000_savevm/hw/ne2000.c	2004-10-01 14:50:42.000000000 +0200
 <at>  <at>  -538,6 +538,59  <at>  <at> 
     return 0;
 }
 
+static void ne2000_save(QEMUFile* f,void* opaque)
+{
+	NE2000State* s=(NE2000State*)opaque;
+
+	qemu_put_8s(f, &s->cmd);
+	qemu_put_be32s(f, &s->start);
+	qemu_put_be32s(f, &s->stop);
+	qemu_put_8s(f, &s->boundary);
+	qemu_put_8s(f, &s->tsr);
+	qemu_put_8s(f, &s->tpsr);
+	qemu_put_be16s(f, &s->tcnt);
+	qemu_put_be16s(f, &s->rcnt);
+	qemu_put_be32s(f, &s->rsar);
(Continue reading)

Renzo Davoli | 1 Oct 16:10 2004
Picon

Re: Patch: Sparc system support

On Fri, Oct 01, 2004 at 12:23:07AM +0200, Fabrice Bellard wrote:
> I applied your patches with some modifications. Please update your 
> sources with the CVS version and tell me if you see problems in my 
> modifications.
Yes, I do ;-)

With the latest cvs I get stuck during the compilation inside
sparc-user. (I am working on a linuxppc host)

In file included from
/....... /qemu/translate-all.c:41:
op.h: In function `dyngen_code':
op.h:4781: error: parse error before ')' token
op.h:4782: error: parse error before ')' token
op.h:4797: error: parse error before ')' token
op.h:4798: error: parse error before ')' token

In fact there is something wrong in the op.h file:

Line 4778:
case INDEX_op_fitos: {
    extern void op_fitos();
    memcpy(gen_code_ptr, (void *)((char *)&op_fitos+0), 56);
    *(uint16_t *)(gen_code_ptr + 26) = ((long)(&) + 0 + 0x8000) >> 16;
    *(uint16_t *)(gen_code_ptr + 30) = ((long)(&) + 0);
    gen_code_ptr += 56;
}

(long)(&) .... the operand is missing.

(Continue reading)

zitu | 1 Oct 16:25 2004
Picon

kernel 2.6 losing too many ticks

Hi,

Host=XP
Guest=linux lfs 2.6.5 (from a bootlfs cd iso)

When I try to boot under qemu 0.6 and above, it takes forever.
This does not happen with 2.4 kernels. Anyway to fix this else
than recompiling the 2.6 kernel ?

On a side-line, does qemu-fast exist for win32 ?

Rgds,
Zitu

--

Gmane