Re: [Qemu-devel] Qemu + Windows

[Michael Noisternig]

Is there somewhere a Windows build available for download that has old 
that patches incorporated? Sorry, but I don't want to download and 
install MingW just for compiling Qemu.

Thanks again,
Michael Noisternig


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu + Windows

[Michael Noisternig]

The problem is that the official binary on the sf website doesn't print *anything* 
because of this. Not even on "qemu -h".


Oh, wait a minute, there is no official windows build, on the homepage I 
meant. I was talking about the windows build that is linked to at the 
homepage.



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu + Windows

[Michael Noisternig]

several things don't work on Windows, as you certainly know. Probably
most of them are easy to fix. E.g. don't write to stderr on Windows, you 
won't see it (unless redirected), (IIRC).


You'll see STDERR output as long as Qemu is compiled as a console
application.


The problem is that the official binary on the sf website doesn't print 
*anything* because of this. Not even on "qemu -h".



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Bug compiling kqemu

[Juergen Bullinger]

Hi all,

sorry if this is already a known problem. I downloaded qemu 0.7.0 and
kqemu 0.6.2-1. First I only compiled qemu 0.7.0 without kqemu on my
machine (which is a AMD Athlon/64 running Fedora Core 3 in the 86_64
distribution).
Qemu worked fine with Win 98.
Then I tried to compile it a second time with kqemu and got the
following problem:


make[1]: Entering directory
`/home/juergen/downloads/qemu/qemu-0.7.0/kqemu'
make -C /lib/modules/2.6.11-1.27_FC3/build M=`pwd` modules
make[2]: Entering directory `/lib/modules/2.6.11-1.27_FC3/build'
  CC [M]  /home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kmod.o
cp /home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu-mod-
i386.o /home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu-mod.o
  LD [M]  /home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu.o
ld: Relocatable linking with relocations from format elf32-i386
(/home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu-mod.o) to format
elf64-x86-64 (/home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu.o) is
not supported
make[3]: *** [/home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu.o]
Error 1
make[2]: *** [_module_/home/juergen/downloads/qemu/qemu-0.7.0/kqemu]
Error 2
make[2]: Leaving directory `/lib/modules/2.6.11-1.27_FC3/build'
make[1]: *** [kqemu.ko] Error 2
make[1]: Leaving directory
`/home/juergen/downloads/qemu/qemu-0.7.0/kqemu'
make: *** [all] Error 2
[EMAIL PROTECTED] qemu-0.7.0]$


Is this problem already known?
Is there already a workaround?


BTW: qemu is great! Thank you folks! 
When I compiled it I got many warnings about pointer-to-int conversions
which could lead to problems, but it worked fine. I guess it was just,
because my system is 64 bit. If you like to remove these warnings I
could send you the output of the make process.

Thank you in advance

Juergen

-- 
Juergen Bullinger <[EMAIL PROTECTED]>



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu sandbox for teaching

[Herbert Poetzl]

On Sat, May 28, 2005 at 07:50:53PM +0200, Jerome Warnier wrote:
> Le samedi 28 mai 2005 à 14:13 +0100, Paul Brook a écrit :
> > On Saturday 28 May 2005 13:42, Jerome Warnier wrote:
> > > Does someone here have an idea on how to do the following using Qemu,
> > > but I'm open to other suggestions:
> > >
> > > I would like to provide a UNIX CLI sandbox for users to poke around in a
> > > UNIX course. It would be better if available from the web (preferably
> > > without having to install anything on the users' PC), and Free (as in
> > > free speach).
> > > The problem is that I need to give them root access, or at least a
> > > simulation.
> > > It would be even better if we could for instance install RedHat in it,
> > > but it's not really required.
> > 
> > It's not really answering your question, but qemu is probably OTT for this. 
> > If 
> > I was setting this up I'd use UML and a java web based telnet/ssh client.
> Well, I was thinking about what the snapshot feature of qemu could bring
> me.
> 
> In fact, I thought about the following solutions:
> - qemu (or whatever other virtualization system)
> - chroot (or specifically dchroot in Debian) and remote telnet or ssh
> access
> - UML
> 
> Advantages of every solution:
> - qemu virtualizes a complete machine, which means installation of an OS
> is possible and it is pretty safe (security-wise) to setup
> - chroot is fast to run and pretty safe
> - UML is fast to run and pretty safe
> 
> Problems of every solution:
> - qemu is slow, and a lot of virtual machines at the same time on the
> same machine will slow it down and use too much memory, I think (I'm
> talking about 10 people «playing» at the same time). Using only a
> text-mode virtual machine may probably help, though
> - chroot does not allow much and may take time to setup correctly
> - UML is difficult to setup, and needs a kernel patch (even on 2.6?) to

you might want to have a look at linux-vserver

http://linux-vserver.org/

it allows you to have VPS with certain root rights
on a shared host, in a secure manner (no overhead)

HTH,
Herbert

> work
> 
> 
> > Paul
> -- 
> Jerome Warnier <[EMAIL PROTECTED]>
> BeezNest
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[Tero Kaarlela]

J. Mayer wrote:


On Wed, 2005-05-25 at 21:59 +0300, Tero Kaarlela wrote:
 

I have just realized that when running in LE mode in_asm dump is not 
useful because it shows code in BE-format. I'll try to make it print in 
LE format. And those invalid opcodes is this because after OS/2 crashes 
Qemu tries to start its own code but crashes because before this 
Processor should be returned to BE-format?
   



It should display insns in little-endian format, if you're up to date.
Take a look at the code in disas.c and ppc-dis.c, you'll see the case is
handled.
 


Yes I  used out of date binaries(0.6.1 + patches). My mistake sorry.


But the 0x3c opcode is valid ... on POWER2 (namely stfq).
Then I guess you choose a platform which is a RS/6000 with a POWER2, not
a PowerPC.
I'm afraid POWER1 & POWER2 won't be emuled soon, if they'll ever be...
Please check this point.


Bootloader check PVR at very early stage of boot accepted ones are:

   601
   603
   604

 If something else is reported bootloader goes to indefiniteve loop.


Another point:
 

   I took a look at qemu in_asm & cpu debugging with OS/2 bootloader 
under Qemu -prep. And there is something weird happening in my opinion:


This happens after boot.cfg has been gone through and kernel bootstrap 
task should start:


IN:
0xf0107068:  .long 0x10009d81
0xf010706c:  tdi0,r0,27776
0xf0107070:  blF011EDF0<<= Shouldnt this branch to F011EDF0 
instead of going on???
   



As this is a subroutine call, I guess this routine as already been called from 
somewhere else.
As Qemu only displays blocks at translation time, you don't have any dump any 
more
when calling a routine twice.


 After compiling CVS version lines above look like this:

IN:
0xf0107068:  lwzr12,16(r29)
0xf010706c:  lwzr3,8(r12)
0xf0107070:  lwzr11,328(r29)
0xf0107074:  cmpwir11,0
0xf0107078:  beqF01070A4

invalid/unsupported opcode: 3c - 16 - 0a (f01072ac) 0x0300 0
IN:
0x0300:  .long 0xf01072ac

invalid/unsupported opcode: 3c - 18 - 1c (f730) 0x0700 0
IN:
0x0700:  .long 0xf730

Could this be because OS/2 can't handle this much ram(128mb). OS/2 has 
always been very specific about maximum memory(ie. versions 1.x can't 
boot on machines that report more than 16mb ram. this is one of the 
reasons 1.x versions dont boot under Qemu and thats why many BIOSES have 
option "boot to OS/2). During 1995 when OS/2 PPC was made 16mb was much 
and 32mb was huge amount of memory.


Tero Kaarlela




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] CVS : No longer boots a W2K image

[Emmanuel Charpentier]

Dear List,

I recently upgraded to QEMU 0.7.0 (self-compiled with kqemu on top of
Debian Sid). It worked fine, but I was unable to use the new 1152x960 an
1280x1024 graphics mode in most case, image seriously garbled, and
reverting to 640x480x8 in the remainder of cases ; 1024x768x16 is still
OK after a reboot of the virtual machine).

So I decided to try the CVS version. The very same command line now
gives me the Bios page telling that the image is not bootable.

Reverting to the former version (0.7.0) still works fine. So I think
this is a problem specific to this CVS version.

The image is a 4 Gb Win2K .cow image created circa Oct, 2004 (0.6.1,
IIRC) with qemu-mkcow.

Any hints ?

Emmanuel Charpentier

PS : I'd appreciate a Cc: to my own address, since I'm not on the list
and read it through the gmane archive...



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] cocoa.m using openGL

[Pierre d'Herbemont]

On 28 mai 05, at 20:39, Mike Kronenberg wrote:Pierre d'Herbemont wrote:It doesn't work on my iMac DV G3 400. I know that its ATI Rage 128 is very limited, but I think that we'll had to keep both version...Did You get an error-message so we could include a autoswitch?Nop... The main window's buffer seems to point to a wrong memory address. I have seen, this bug before when playing with OpenGL and texture on this Macine. Screenshot here:http://stegefin.free.fr/q-ogl.pngPierre.___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Pierre d'Herbemont]

On 28 mai 05, at 20:36, Mike Kronenberg wrote:Pierre d'Herbemont wrote:That  should be done with not much troubles, if we manage to get qemu  thread safe. Did you try that way? Until the 7. May I was trying to get all into qemu... sources are still there.I was looking into making the contoller one thread and the each qemu a thread, so one can run multiple qemus. It is still on the List - but it's a little more time intensive (I use qemu for my work) . So I gutted cocoa.m to the elemental UI things... like it is now and made a controller with the features I need a lot and I think would be useful to have in the final product.I would like very much, that my patch would be comitted, so bugs can be fixed and features added.As soon as we can make qemu threadsave, it's easy to merge the working frontend with qemu.For now a single-threaded qemu could be ok... The patch will be smaller, and the multiple instance feature may be added later. What do you think?Pierre.___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu + Windows

[Jernej Simonèiè]

On Sunday, May 29, 2005, 11:34:42, Michael Noisternig wrote:

> The problem is that the official binary on the sf website doesn't print
> *anything* because of this. Not even on "qemu -h".

I posted a program that can change that here:


-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

Nothing is impossible for the man who doesn't have to do it himself.
   -- Weiler's Law



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Bug compiling kqemu

[Ishwar Rattan]

On Sun, 29 May 2005, Juergen Bullinger wrote:
>   LD [M]  /home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu.o
> ld: Relocatable linking with relocations from format elf32-i386
> (/home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu-mod.o) to format
> elf64-x86-64 (/home/juergen/downloads/qemu/qemu-0.7.0/kqemu/kqemu.o) is
> not supported
  ^
Probably the kernel patch does not work for 64-bit
kernel scenario, read the error carefully.

-ishwar



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] weird errors on x86_64 target (i686 host)

[VMiklos]

VMiklos wrote:
i just tried out the new x86_64 target (version 0.7.0), wanted to 
install a gentoo system.


i downloaded the install livecd:

http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/releases/amd64/2005.0/installcd/install-amd64-minimal-2005.0.iso 

here are the first problem. most commands works fine, but for example if 
you try to 'ssh someserver', it'll fail


the full installation works fine, you can boot the target system, but 
major upgrades (gcc, glibc compilations) fails with internal compiler error


yes, i checked that if i do the same on a real x86_64 host, it compiles 
without any problem


if you need any additional info pls let me know


any ideas?

udv / greetings,
VMiklos


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel