Re: [Qemu-devel] Updated RFC: linux user problems]]

2007-09-25 Thread J. Mayer
On Mon, 2007-09-24 at 22:39 -0600, Thayne Harbaugh wrote:
 I've often wondered why there isn't a tswap_target_ulong().  Seems like
 using tswap32() is asking for trouble.

Isn't it tswapl ?

-- 
J. Mayer [EMAIL PROTECTED]
Never organized





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Dan Kenigsberg
On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
 Hi,
 
 On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
  As with previous Takes of this patch, its purpose is to expose host
  +{
  +asm(cpuid
  +: =a (*ax),
  +  =b (*bx),
  +  =c (*cx),
  +  =d (*dx)
  +: a (function));
  +}
 
 I haven't really read through the rest of your code but this piece
 appears to be outside any #ifdef/#endif so it will only build on x86.

I might be missing something here, but isn't not being on the
TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
elsewhere under target-i386. I don't mind adding extra protection, I
just be happy to better understand the whats and whys.

Dan.




Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity
Dan Kenigsberg wrote:
 On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
   
 Hi,

 On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
 
 As with previous Takes of this patch, its purpose is to expose host
 +{
 +asm(cpuid
 +: =a (*ax),
 +  =b (*bx),
 +  =c (*cx),
 +  =d (*dx)
 +: a (function));
 +}
   
 I haven't really read through the rest of your code but this piece
 appears to be outside any #ifdef/#endif so it will only build on x86.
 

 I might be missing something here, but isn't not being on the
 TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
 elsewhere under target-i386. I don't mind adding extra protection, I
 just be happy to better understand the whats and whys.
   

target-i386 means the guest will run i386 instructions, but the host can
be something else (say, powerpc).

Nothing else uses host instructions in that directory, so no protection
was necessary before.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread J. Mayer
On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
 Dan Kenigsberg wrote:
  On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:

  Hi,
 
  On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
  
  As with previous Takes of this patch, its purpose is to expose host
  +{
  +asm(cpuid
  +: =a (*ax),
  +  =b (*bx),
  +  =c (*cx),
  +  =d (*dx)
  +: a (function));
  +}

  I haven't really read through the rest of your code but this piece
  appears to be outside any #ifdef/#endif so it will only build on x86.
  
 
  I might be missing something here, but isn't not being on the
  TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
  elsewhere under target-i386. I don't mind adding extra protection, I
  just be happy to better understand the whats and whys.

 
 target-i386 means the guest will run i386 instructions, but the host can
 be something else (say, powerpc).
 
 Nothing else uses host instructions in that directory, so no protection
 was necessary before.

I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Then, an external tool (even a shell script) can be
used to determine what is the host CPU if you want to select the exact
same CPU to be emulated in Qemu. It seems to me that trying to do so is
out of the scope of Qemu code and just add unneeded complexity.

Regards.

-- 
J. Mayer [EMAIL PROTECTED]
Never organized





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity
J. Mayer wrote:
 On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
   
 Dan Kenigsberg wrote:
 
 On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
   
   
 Hi,

 On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
 
 
 As with previous Takes of this patch, its purpose is to expose host
 +{
 +asm(cpuid
 +: =a (*ax),
 +  =b (*bx),
 +  =c (*cx),
 +  =d (*dx)
 +: a (function));
 +}
   
   
 I haven't really read through the rest of your code but this piece
 appears to be outside any #ifdef/#endif so it will only build on x86.
 
 
 I might be missing something here, but isn't not being on the
 TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
 elsewhere under target-i386. I don't mind adding extra protection, I
 just be happy to better understand the whats and whys.
   
   
 target-i386 means the guest will run i386 instructions, but the host can
 be something else (say, powerpc).

 Nothing else uses host instructions in that directory, so no protection
 was necessary before.
 

 I've got a remark about this: why this has to be added to the Qemu
 code ?
 Imho, all is needed is an implementation of the -cpu option for
 x86/x86_64 target. Then, an external tool (even a shell script) can be
 used to determine what is the host CPU if you want to select the exact
 same CPU to be emulated in Qemu. It seems to me that trying to do so is
 out of the scope of Qemu code and just add unneeded complexity.
   

Indeed for regular qemu this is useless.  But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





Re: [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Fabrice Bellard

andrzej zaborowski wrote:

Hi,

On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:


As with previous Takes of this patch, its purpose is to expose host
CPU features to guests. It proved rather helpful to KVM in various
benchmarks, and it should similarly speed kqemu up. Note that it does
not extend the set of emulated opcodes, only exposes what's supported by
the host CPU.

Another purpose for Take 2 is to add the -cpu option to the x86
architecture, similarly to that of other architectures.
-cpu 486, pentium, pentium2 and pentium3 are supported in addition to
finer-grained features such as -cpu pentium,-mmx . As in Take 1,
-cpu host exposes host features to guest.

This patch exposes the requested CPU also right after RESET command, and
not only in CPUID.

Please let me know if you have more suggestions,

Dan.

[...]

I haven't really read through the rest of your code but this piece
appears to be outside any #ifdef/#endif so it will only build on x86.

Regards


A few remarks:

1) I cannot accept GPL code in target-i386, so the code from the Linux 
kernel must be removed or rewritten.


2) cpuid is already defined in kqemu.c, so it would be better to use it 
(I consider this is not a blocking point though).


3) For the future, I suggest that the function cpu_xxx_register() is 
removed and that the parameter xxx_def_t is added to cpu_xxx_init().


Rationale: I see no point in initializing a CPU without specifying its 
exact model and I am not sure that cpu_xxx_register() can be called once 
some code is executed.


Regards,

Fabrice.




[Qemu-devel] Serial Console / NoGraphic

2007-09-25 Thread Clemens Kolbitsch
hi!
i've been trying around for quite some time now trying to start qemu without 
the graphic screen... can someone tell me exactly what I'm supposed to do??

i want to redirect the output of my i386 debian linux to my host-console (also 
a i386 debian) to fully see the output of a kernel panic (see previous 
messages i have posted).

i'm starting qemu:

qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd 
myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic

after tons of trial-and-error i finally got my system to boot, however, the 
login-screen is not displayed (i see all output of the starting system up 
until the login:). how do i connect to the serial line now to get to the 
login??

i have tried minicom, however that seems to just hang :-(

should i use (tell qemu to use) a different virtual serial console?? how to 
i start minicom correctly?? could you give me the parameter set you guys are 
using for
1.) qemu
2.) connector (minicom???)
3.) what i have to enable inside my guest-system (i have checked 
that /etc/securetty include ttyS0 already)

any help will - as always - be greatly appreciated!!
thanks :-)




Re: [Qemu-devel] Serial Console / NoGraphic

2007-09-25 Thread Michael McConnell

Clemens Kolbitsch wrote:

hi!
i've been trying around for quite some time now trying to start qemu without 
the graphic screen... can someone tell me exactly what I'm supposed to do??


i want to redirect the output of my i386 debian linux to my host-console (also 
a i386 debian) to fully see the output of a kernel panic (see previous 
messages i have posted).


i'm starting qemu:

qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd 
myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic


after tons of trial-and-error i finally got my system to boot, however, the 
login-screen is not displayed (i see all output of the starting system up 
until the login:). how do i connect to the serial line now to get to the 
login??


Add this to /etc/inittab in the guest system:
co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav

Without that it's only going to put the login prompts on the (now 
hidden) virtual consoles.


The (emulated) hardware display still exists, it's just not shown. I use 
just such a setup for a Win2000 virtual-machine that's accessible by 
VNC. I've had issues with QEMU's own VNC server (it crashes with a core 
dump on disconnection, and no-one on the list was remotely interested) 
so instead I run UltraVNC within Win2000 and connect to that instead.


--
-- Michael Soruk McConnell
   Eridani Star System

   MailStripper - http://www.MailStripper.eu/ - UNIX spam filter
   Mail Me Anywhere - http://www.mailmeanywhere.com/ - email for phones





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity
Avi Kivity wrote:
 
   
 I've got a remark about this: why this has to be added to the Qemu
 code ?
 Imho, all is needed is an implementation of the -cpu option for
 x86/x86_64 target. Then, an external tool (even a shell script) can be
 used to determine what is the host CPU if you want to select the exact
 same CPU to be emulated in Qemu. It seems to me that trying to do so is
 out of the scope of Qemu code and just add unneeded complexity.
   
 

 Indeed for regular qemu this is useless.  But it is useful for kqemu
 (for which there is support in mainline qemu), and for kvm (which we
 hope to merge one day).

   

Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
it can't trap cpuid in all circumstances.

So this is mainly useful for kvm.  I hope it will be applied regardless
of that, as there is agreement that kvm support should be merged.  I'd
much rather pull the feature from qemu rather than carry it as an
additional patch.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread J. Mayer
On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
 Avi Kivity wrote:
  

  I've got a remark about this: why this has to be added to the Qemu
  code ?
  Imho, all is needed is an implementation of the -cpu option for
  x86/x86_64 target. Then, an external tool (even a shell script) can be
  used to determine what is the host CPU if you want to select the exact
  same CPU to be emulated in Qemu. It seems to me that trying to do so is
  out of the scope of Qemu code and just add unneeded complexity.

  
 
  Indeed for regular qemu this is useless.  But it is useful for kqemu
  (for which there is support in mainline qemu), and for kvm (which we
  hope to merge one day).
 

 
 Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
 it can't trap cpuid in all circumstances.
 
 So this is mainly useful for kvm.  I hope it will be applied regardless
 of that, as there is agreement that kvm support should be merged.  I'd
 much rather pull the feature from qemu rather than carry it as an
 additional patch.

Still I don't understand why it's usefull to put it inside the emulator
and why:
# qemu -cpu `guess_host_cpu`
would not do the work properly. Adding a specific case for '-cpu host'
seems useless to me.
And this way of doing potentially work for any family of emulated
targets, without any modification in Qemu. If the string returned by
'guess_host_cpu' is not recognized for the specific target you used it
with, Qemu just stops telling it cannot find this CPU model, no more, no
less.
The only case it could be interresting, imho, is if you do not allow the
-cpu option in KVM case and force the cpu model instead using this
function. This behavior does not seem to be great idea to me.

Or maybe I missed something ?

-- 
J. Mayer [EMAIL PROTECTED]
Never organized





[Qemu-devel] Re: Serial Console / NoGraphic

2007-09-25 Thread Clemens Kolbitsch
On Tuesday 25 September 2007 12:04:17 Clemens Kolbitsch wrote:
 hi!
 i've been trying around for quite some time now trying to start qemu
 without the graphic screen... can someone tell me exactly what I'm supposed
 to do??

 i want to redirect the output of my i386 debian linux to my host-console
 (also a i386 debian) to fully see the output of a kernel panic (see
 previous messages i have posted).

 i'm starting qemu:

 qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd
 myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic

 after tons of trial-and-error i finally got my system to boot, however, the
 login-screen is not displayed (i see all output of the starting system up
 until the login:). how do i connect to the serial line now to get to
 the login??

 i have tried minicom, however that seems to just hang :-(

 should i use (tell qemu to use) a different virtual serial console?? how
 to i start minicom correctly?? could you give me the parameter set you guys
 are using for
 1.) qemu
 2.) connector (minicom???)
 3.) what i have to enable inside my guest-system (i have checked
 that /etc/securetty include ttyS0 already)

 any help will - as always - be greatly appreciated!!
 thanks :-)

hi!
i finally found out that it was all just a configuration problem inside my 
guest :-)

for anyone having the same problem: 

qemu myimage -serial stdio -nographic

is totally sufficient as long as you tell linux to start getty listening on a 
serial console (make sure that GRUB tells your kernel to 
include console=/dev/ttyS0).

in my case (a newer debian system) this was adding a file to
/etc/event.d/ called ttyS0

containing the line

/sbin/getty -L /dev/ttyS0 38400 vt100

maybe it helps someone :-)




Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

2007-09-25 Thread Derek Fawcus
On Mon, Sep 24, 2007 at 11:22:30PM +0200, Fabrice Bellard wrote:
 I realize that the other pixel formats are buggy too, so at least your 
 patch is consistent with what is already coded !
 
 I guess the problem is in the VGA memory handlers. Otherwise it means 
 that there is a (Cirrus)VGA configuration register to change the 
 endianness of the frame buffer. In such case, it must be emulated correctly.

I don't know about a register (w/o reading the docs),  but I seem to recall
that it does have a second PCI FB window which is byte swapped specifically
for BE machines...

DF




Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity
J. Mayer wrote:
 On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
   
 Avi Kivity wrote:
 
 
   
   
 I've got a remark about this: why this has to be added to the Qemu
 code ?
 Imho, all is needed is an implementation of the -cpu option for
 x86/x86_64 target. Then, an external tool (even a shell script) can be
 used to determine what is the host CPU if you want to select the exact
 same CPU to be emulated in Qemu. It seems to me that trying to do so is
 out of the scope of Qemu code and just add unneeded complexity.
   
 
 
 Indeed for regular qemu this is useless.  But it is useful for kqemu
 (for which there is support in mainline qemu), and for kvm (which we
 hope to merge one day).

   
   
 Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
 it can't trap cpuid in all circumstances.

 So this is mainly useful for kvm.  I hope it will be applied regardless
 of that, as there is agreement that kvm support should be merged.  I'd
 much rather pull the feature from qemu rather than carry it as an
 additional patch.
 

 Still I don't understand why it's usefull to put it inside the emulator
 and why:
 # qemu -cpu `guess_host_cpu`
 would not do the work properly. Adding a specific case for '-cpu host'
 seems useless to me.
 And this way of doing potentially work for any family of emulated
 targets, without any modification in Qemu. If the string returned by
 'guess_host_cpu' is not recognized for the specific target you used it
 with, Qemu just stops telling it cannot find this CPU model, no more, no
 less.
   

It's a usability issue.  I agree your suggestion would work, but I'd
like the default for kvm to be using the host cpu features, whereas
managed environments would specify some subset to enable live migration.

 The only case it could be interresting, imho, is if you do not allow the
 -cpu option in KVM case and force the cpu model instead using this
 function. This behavior does not seem to be great idea to me.
   

I think we can move the host cpu checks to kvm-specific code, since it
is not useful for kqemu.

So, running qemu without any parameters would use host capabilities if
kvm is available and the default qemu cpu if not.  The -cpu option can
be used to override this if necessary.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





Re: [Qemu-devel] Serial Console / NoGraphic

2007-09-25 Thread GUERRAZ Francois
Hi Michael,

About your VNC problems : I have had problems w/ vnc too (see
http://qemu-forum.ipi.fi/viewtopic.php?p=10468) but had no answer as
well...

Anyway, it's better to do like you're doing : installing a VNC server
inside the vm is much better because you can have authentication and
such things... and no mouse / keyboard issues.

I'm using Qemu VNC server for the Qemu supervisor I'm developing (see
http://sourceforge.net/projects/casimir-web/ ) and it works very well
this way : ask qemu vnc to listen in a socket (-vnc
unix:/tmp//vmXXX.vnc) and use socat to make it listen on a tcp port when
you need it (socat TCP4-LISTEN:port UNIX-CONNECT:socket), socat will
die when the connexion closes, not Qemu :)
I don't know if it is because of the socat thing, but I don't have
problems anymore...

Le mardi 25 septembre 2007 à 11:11 +0100, Michael McConnell a écrit :
 Clemens Kolbitsch wrote:
  hi!
  i've been trying around for quite some time now trying to start qemu 
  without 
  the graphic screen... can someone tell me exactly what I'm supposed to do??
  
  i want to redirect the output of my i386 debian linux to my host-console 
  (also 
  a i386 debian) to fully see the output of a kernel panic (see previous 
  messages i have posted).
  
  i'm starting qemu:
  
  qemu -hda myimage -boot c -kernel-kqemu -kernel mykernel -initrd 
  myinitrd -append root=/dev/hda1 console=/dev/ttyS0 -nographic
  
  after tons of trial-and-error i finally got my system to boot, however, the 
  login-screen is not displayed (i see all output of the starting system up 
  until the login:). how do i connect to the serial line now to get to 
  the 
  login??
 
 Add this to /etc/inittab in the guest system:
 co:2345:respawn:/sbin/agetty ttyS0 9600 vt100-nav
 
 Without that it's only going to put the login prompts on the (now 
 hidden) virtual consoles.
 
 The (emulated) hardware display still exists, it's just not shown. I use 
 just such a setup for a Win2000 virtual-machine that's accessible by 
 VNC. I've had issues with QEMU's own VNC server (it crashes with a core 
 dump on disconnection, and no-one on the list was remotely interested) 
 so instead I run UltraVNC within Win2000 and connect to that instead.
 





Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

2007-09-25 Thread Dan Kenigsberg
On Thu, Sep 20, 2007 at 02:41:32PM +0100, Daniel P. Berrange wrote:
 On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote:
  Hi,
  
  I saw that using the tablet with Linux guest is possible
  http://thread.gmane.org/gmane.comp.emulators.qemu/11516
  yet I fail to do that.
  
  I managed to compile, configure and load the evtouch X module, but still
  there is no movement of the mouse (after I disabled the default X
  pointer). I attach my Xorg.0.log for the joy of the readership.
 
 Don't use the evtouch X module. Use the regular 'evdev' module.
 
 Dan.

Dan, thanks for this info. However, my problem begins earlier than in X
and using evdev instead of evtouch does not solve it.

It seems that some Linux guests have problems communicating with the
tablet device. The most reproducible behavior that I noticed is when
FC-6 starts: gpm senses the tablet, but only until haldaemon starts.
After that, I cannot obtain any mouse event (even after stopping
haldaemon).

Could you tell if this can be avoided?

Thanks,

Dan.




Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Fabrice Bellard

Avi Kivity wrote:

J. Mayer wrote:


On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
 


Avi Kivity wrote:
   

   
 
 


I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Then, an external tool (even a shell script) can be
used to determine what is the host CPU if you want to select the exact
same CPU to be emulated in Qemu. It seems to me that trying to do so is
out of the scope of Qemu code and just add unneeded complexity.
 
   
   


Indeed for regular qemu this is useless.  But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).

 
 


Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
it can't trap cpuid in all circumstances.

So this is mainly useful for kvm.  I hope it will be applied regardless
of that, as there is agreement that kvm support should be merged.  I'd
much rather pull the feature from qemu rather than carry it as an
additional patch.
   


Still I don't understand why it's usefull to put it inside the emulator
and why:
# qemu -cpu `guess_host_cpu`
would not do the work properly. Adding a specific case for '-cpu host'
seems useless to me.
And this way of doing potentially work for any family of emulated
targets, without any modification in Qemu. If the string returned by
'guess_host_cpu' is not recognized for the specific target you used it
with, Qemu just stops telling it cannot find this CPU model, no more, no
less.
 



It's a usability issue.  I agree your suggestion would work, but I'd
like the default for kvm to be using the host cpu features, whereas
managed environments would specify some subset to enable live migration.



The only case it could be interresting, imho, is if you do not allow the
-cpu option in KVM case and force the cpu model instead using this
function. This behavior does not seem to be great idea to me.
 



I think we can move the host cpu checks to kvm-specific code, since it
is not useful for kqemu.

So, running qemu without any parameters would use host capabilities if
kvm is available and the default qemu cpu if not.  The -cpu option can
be used to override this if necessary.


Rectification: this is useful for kqemu too. I strongly suggest to look 
at kqemu.c:kqemu_update_cpuid() !


Moreover I believe that using the same CPU as host can be useful for 
pure emulation too, for example if code to do cache profiling is added.


Regards,

Fabrice.




[Qemu-devel] vmmouse with Fedora-6 64bit guest

2007-09-25 Thread Dan Kenigsberg
Frustrated with evtouch, I wanted to try vmmouse's absolute mode, supported by
Liguori's patch http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .

My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
However, for some reason I get
(EE) VMWARE(0): vmmouse enabled failed

On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
nothing else.

Any idea what I am doing wrong?

Regards,
Dan.




Re: [Qemu-devel] [PATCH] linux-user sigaltstack() syscall

2007-09-25 Thread Thayne Harbaugh
On Mon, 2007-09-24 at 23:04 -0600, Thayne Harbaugh wrote:
 This patch adds the sigaltstack() syscall for linux-user.

The previous patch relied on the EFAULT patch, this newer version does
not.  It also fixes a few places that used tswap32() that should use
__put_user().
Index: qemu/linux-user/signal.c
===
--- qemu.orig/linux-user/signal.c	2007-09-25 05:46:34.0 -0600
+++ qemu/linux-user/signal.c	2007-09-25 06:35:23.0 -0600
@@ -26,6 +26,7 @@
 #include errno.h
 #include sys/ucontext.h
 
+#include target_signal.h
 #include qemu.h
 
 //#define DEBUG_SIGNAL
@@ -45,6 +46,12 @@
  first signal, we put it here */
 };
 
+struct target_sigaltstack target_sigaltstack_used = {
+.ss_sp = 0,
+.ss_size = 0,
+.ss_flags = TARGET_SS_DISABLE,
+};
+
 static struct emulated_sigaction sigact_table[TARGET_NSIG];
 static struct sigqueue sigqueue_table[MAX_SIGQUEUE_SIZE]; /* siginfo queue */
 static struct sigqueue *first_free; /* first free siginfo queue entry */
@@ -92,6 +99,18 @@
 };
 static uint8_t target_to_host_signal_table[65];
 
+static inline int on_sig_stack(unsigned long sp)
+{
+return (sp - target_sigaltstack_used.ss_sp
+ target_sigaltstack_used.ss_size);
+}
+
+static inline int sas_ss_flags(unsigned long sp)
+{
+return (target_sigaltstack_used.ss_size == 0 ? SS_DISABLE
+: on_sig_stack(sp) ? SS_ONSTACK : 0);
+}
+
 static inline int host_to_target_signal(int sig)
 {
 return host_to_target_signal_table[sig];
@@ -419,6 +438,67 @@
 }
 }
 
+int do_sigaltstack(const struct target_sigaltstack *uss,
+   struct target_sigaltstack *uoss,
+   target_ulong sp)
+{
+int ret;
+struct target_sigaltstack oss;
+
+/* XXX: test errors */
+if(uoss)
+{
+__put_user(target_sigaltstack_used.ss_sp, oss.ss_sp);
+__put_user(target_sigaltstack_used.ss_size, oss.ss_size);
+__put_user(sas_ss_flags(sp), oss.ss_flags);
+}
+
+if(uss)
+{
+	struct target_sigaltstack ss;
+
+	ret = -EFAULT;
+	if (!access_ok(VERIFY_READ, uss, sizeof(*uss))
+	|| __get_user(ss.ss_sp, uss-ss_sp)
+	|| __get_user(ss.ss_size, uss-ss_size)
+	|| __get_user(ss.ss_flags, uss-ss_flags))
+goto out;
+
+	ret = -EPERM;
+	if (on_sig_stack(sp))
+goto out;
+
+	ret = -EINVAL;
+	if (ss.ss_flags != TARGET_SS_DISABLE
+ ss.ss_flags != TARGET_SS_ONSTACK
+ ss.ss_flags != 0)
+goto out;
+
+	if (ss.ss_flags == TARGET_SS_DISABLE) {
+ss.ss_size = 0;
+ss.ss_sp = 0;
+	} else {
+ret = -ENOMEM;
+if (ss.ss_size  MINSIGSTKSZ)
+goto out;
+	}
+
+target_sigaltstack_used.ss_sp = ss.ss_sp;
+target_sigaltstack_used.ss_size = ss.ss_size;
+}
+
+if (uoss) {
+ret = -EFAULT;
+if (!access_ok(VERIFY_WRITE, uoss, sizeof(oss)))
+goto out;
+memcpy(uoss, oss, sizeof(oss));
+}
+
+ret = 0;
+out:
+return ret;
+}
+
 int do_sigaction(int sig, const struct target_sigaction *act,
  struct target_sigaction *oact)
 {
@@ -551,12 +631,6 @@
 	target_ulong cr2;
 };
 
-typedef struct target_sigaltstack {
-	target_ulong ss_sp;
-	int ss_flags;
-	target_ulong ss_size;
-} target_stack_t;
-
 struct target_ucontext {
 target_ulong	  tuc_flags;
 	target_ulong  tuc_link;
@@ -640,16 +714,14 @@
 
 	/* Default to using normal stack */
 	esp = env-regs[R_ESP];
-#if 0
 	/* This is the X/Open sanctioned signal stack switching.  */
-	if (ka-sa.sa_flags  SA_ONSTACK) {
-		if (sas_ss_flags(esp) == 0)
-			esp = current-sas_ss_sp + current-sas_ss_size;
-	}
+if (ka-sa.sa_flags  TARGET_SA_ONSTACK) {
+if (sas_ss_flags(esp) == 0)
+esp = target_sigaltstack_used.ss_sp + target_sigaltstack_used.ss_size;
+}
 
 	/* This is the legacy signal stack switching. */
 	else
-#endif
 if ((env-segs[R_SS].selector  0x) != __USER_DS 
 !(ka-sa.sa_flags  TARGET_SA_RESTORER) 
 ka-sa.sa_restorer) {
@@ -750,11 +822,11 @@
 	/* Create the ucontext.  */
 	err |= __put_user(0, frame-uc.tuc_flags);
 	err |= __put_user(0, frame-uc.tuc_link);
-	err |= __put_user(/*current-sas_ss_sp*/ 0,
+	err |= __put_user(target_sigaltstack_used.ss_sp,
 			  frame-uc.tuc_stack.ss_sp);
-	err |= __put_user(/* sas_ss_flags(regs-esp) */ 0,
+	err |= __put_user(sas_ss_flags(get_sp_from_cpustate(env)),
 			  frame-uc.tuc_stack.ss_flags);
-	err |= __put_user(/* current-sas_ss_size */ 0,
+	err |= __put_user(target_sigaltstack_used.ss_size,
 			  frame-uc.tuc_stack.ss_size);
 	err |= setup_sigcontext(frame-uc.tuc_mcontext, frame-fpstate,
 			env, set-sig[0]);
@@ -880,7 +952,6 @@
 {
 	struct rt_sigframe *frame = (struct rt_sigframe *)g2h(env-regs[R_ESP] - 4);
 sigset_t set;
-//	stack_t st;
 	int eax;
 
 #if 0
@@ -893,13 +964,9 @@
 	if 

Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Paul Brook
On Tuesday 25 September 2007, Avi Kivity wrote:
 J. Mayer wrote:
  On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
  Dan Kenigsberg wrote:
  On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
  Hi,
 
  On 24/09/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote:
  As with previous Takes of this patch, its purpose is to expose host
  +{
  +asm(cpuid
  +: =a (*ax),
  +  =b (*bx),
  +  =c (*cx),
  +  =d (*dx)
  +: a (function));
  +}
 
 Indeed for regular qemu this is useless.  But it is useful for kqemu
 (for which there is support in mainline qemu), and for kvm (which we
 hope to merge one day).

And, as discussed before, it should be asking the hypervisor what features it 
supports instead of trying to guess from the cpuid output.

Paul




Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Jocelyn Mayer
On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote:
 J. Mayer wrote:
  On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:

  Avi Kivity wrote:
  
  


  I've got a remark about this: why this has to be added to the Qemu
  code ?
  Imho, all is needed is an implementation of the -cpu option for
  x86/x86_64 target. Then, an external tool (even a shell script) can be
  used to determine what is the host CPU if you want to select the exact
  same CPU to be emulated in Qemu. It seems to me that trying to do so is
  out of the scope of Qemu code and just add unneeded complexity.

  
  
  Indeed for regular qemu this is useless.  But it is useful for kqemu
  (for which there is support in mainline qemu), and for kvm (which we
  hope to merge one day).
 


  Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
  it can't trap cpuid in all circumstances.
 
  So this is mainly useful for kvm.  I hope it will be applied regardless
  of that, as there is agreement that kvm support should be merged.  I'd
  much rather pull the feature from qemu rather than carry it as an
  additional patch.
  
 
  Still I don't understand why it's usefull to put it inside the emulator
  and why:
  # qemu -cpu `guess_host_cpu`
  would not do the work properly. Adding a specific case for '-cpu host'
  seems useless to me.
  And this way of doing potentially work for any family of emulated
  targets, without any modification in Qemu. If the string returned by
  'guess_host_cpu' is not recognized for the specific target you used it
  with, Qemu just stops telling it cannot find this CPU model, no more, no
  less.

 
 It's a usability issue.  I agree your suggestion would work, but I'd
 like the default for kvm to be using the host cpu features, whereas
 managed environments would specify some subset to enable live migration.
 
  The only case it could be interresting, imho, is if you do not allow the
  -cpu option in KVM case and force the cpu model instead using this
  function. This behavior does not seem to be great idea to me.

 
 I think we can move the host cpu checks to kvm-specific code, since it
 is not useful for kqemu.
 
 So, running qemu without any parameters would use host capabilities if
 kvm is available and the default qemu cpu if not.  The -cpu option can
 be used to override this if necessary.

Well, it may be needed to integrate the -cpu host option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave exactly the same,
whatever the host I'm running on, like any other tool. Think about gcc,
for example, if you launch it without option, it compiles for a generic
CPU. If you want to tune the generated code, even for the host you're
running on, you have to use -mcpu/-march/-mtune. Using one command line
always have gives the same result.
Then, my opinion is that running qemu without any -cpu option should
always use a default target.






Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity

Jocelyn Mayer wrote:

On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote:
  

J. Mayer wrote:


On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
  
  

Avi Kivity wrote:



  
  
  

I've got a remark about this: why this has to be added to the Qemu
code ?
Imho, all is needed is an implementation of the -cpu option for
x86/x86_64 target. Then, an external tool (even a shell script) can be
used to determine what is the host CPU if you want to select the exact
same CPU to be emulated in Qemu. It seems to me that trying to do so is
out of the scope of Qemu code and just add unneeded complexity.
  




Indeed for regular qemu this is useless.  But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).

  
  
  

Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
it can't trap cpuid in all circumstances.

So this is mainly useful for kvm.  I hope it will be applied regardless
of that, as there is agreement that kvm support should be merged.  I'd
much rather pull the feature from qemu rather than carry it as an
additional patch.



Still I don't understand why it's usefull to put it inside the emulator
and why:
# qemu -cpu `guess_host_cpu`
would not do the work properly. Adding a specific case for '-cpu host'
seems useless to me.
And this way of doing potentially work for any family of emulated
targets, without any modification in Qemu. If the string returned by
'guess_host_cpu' is not recognized for the specific target you used it
with, Qemu just stops telling it cannot find this CPU model, no more, no
less.
  
  

It's a usability issue.  I agree your suggestion would work, but I'd
like the default for kvm to be using the host cpu features, whereas
managed environments would specify some subset to enable live migration.



The only case it could be interresting, imho, is if you do not allow the
-cpu option in KVM case and force the cpu model instead using this
function. This behavior does not seem to be great idea to me.
  
  

I think we can move the host cpu checks to kvm-specific code, since it
is not useful for kqemu.

So, running qemu without any parameters would use host capabilities if
kvm is available and the default qemu cpu if not.  The -cpu option can
be used to override this if necessary.



Well, it may be needed to integrate the -cpu host option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave exactly the same,
whatever the host I'm running on, like any other tool. Think about gcc,
for example, if you launch it without option, it compiles for a generic
CPU. If you want to tune the generated code, even for the host you're
running on, you have to use -mcpu/-march/-mtune. Using one command line
always have gives the same result.
Then, my opinion is that running qemu without any -cpu option should
always use a default target.
  


That's a valid usage model.  For many kvm users, however, the primary 
reason to run qemu is to get the performance that kvm provides, so 
they'd like to see host cpuid as the default.  Maybe a .qemurc can help 
here.


--
Any sufficiently difficult bug is indistinguishable from a feature.





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity

Paul Brook wrote:

Indeed for regular qemu this is useless.  But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).



And, as discussed before, it should be asking the hypervisor what features it 
supports instead of trying to guess from the cpuid output.
  


Agreed.

--
Any sufficiently difficult bug is indistinguishable from a feature.





Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Dan Kenigsberg
On Tue, Sep 25, 2007 at 03:07:44PM +0200, Jocelyn Mayer wrote:
  So, running qemu without any parameters would use host capabilities if
  kvm is available and the default qemu cpu if not.  The -cpu option can
  be used to override this if necessary.
 
 Well, it may be needed to integrate the -cpu host option.
 But I think it's a really bad idea that running qemu without the -cpu
 option would not act the same on different host. When I want to test
 qemu with the same command line, I want it to behave exactly the same,
 whatever the host I'm running on, like any other tool. Think about gcc,
 for example, if you launch it without option, it compiles for a generic
 CPU. If you want to tune the generated code, even for the host you're
 running on, you have to use -mcpu/-march/-mtune. Using one command line
 always have gives the same result.
 Then, my opinion is that running qemu without any -cpu option should
 always use a default target.

Note that in take 3 the default is indeed to expose the basic
default cpu features if no -cpu is specified. One must add -cpu host in
order to read and expose the host cpuid.




Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

2007-09-25 Thread Dor Laor

Dan Kenigsberg wrote:

Frustrated with evtouch, I wanted to try vmmouse's absolute mode, supported by
Liguori's patch http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .

My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
However, for some reason I get
(EE) VMWARE(0): vmmouse enabled failed

On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
nothing else.

Any idea what I am doing wrong?

Regards,
Dan.



  
Please dive further into this by debugging the emulator(qemu)/driver 
themselves.

good luck :)




Re: [Qemu-devel] vmmouse with Fedora-6 64bit guest

2007-09-25 Thread Anthony Liguori

Dor Laor wrote:

Dan Kenigsberg wrote:
Frustrated with evtouch, I wanted to try vmmouse's absolute mode, 
supported by
Liguori's patch 
http://thread.gmane.org/gmane.comp.emulators.qemu/16083 .


Did you try it in KVM or in QEMU?

In KVM, you need an additional patch to ensure that the register state 
is synchronized.


Regards,

Anthony LIguori


My guest has vmmouse_drv.so, and I configured its xorg.conf to load it.
However, for some reason I get
(EE) VMWARE(0): vmmouse enabled failed

On the host side, after define DEBUG_VMMOUSE, I see vmmouse_init and
nothing else.

Any idea what I am doing wrong?

Regards,
Dan.



  
Please dive further into this by debugging the emulator(qemu)/driver 
themselves.

good luck :)









[Qemu-devel] qemu readline.c

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 14:45:24

Modified files:
.  : readline.c 

Log message:
Improve completion in monitor, by Pascal Terjan.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/readline.c?cvsroot=qemur1=1.5r2=1.6





[Qemu-devel] qemu block-vvfat.c

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 14:47:03

Modified files:
.  : block-vvfat.c 

Log message:
vvfat mbr fixes, by Ivan Kalvachev.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/block-vvfat.c?cvsroot=qemur1=1.10r2=1.11




[Qemu-devel] qemu/target-mips cpu.h helper.c op.c translate.c

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 14:49:47

Modified files:
target-mips: cpu.h helper.c op.c translate.c 

Log message:
Optimise instructions accessing CP0, by Aurelien Jarno.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.44r2=1.45
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.49r2=1.50
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.72r2=1.73
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.101r2=1.102




[Qemu-devel] [PATCH] SVM VINTR fix

2007-09-25 Thread Alexander Graf
Hi,

in the recently introduced svm patch I misread the documentation and so
a bug came to get included in there. This patch should fix the virtual
interrupt handling completely and thus makes gfxboot work in the
virtualized machine.

Please apply this.

Thanks,

Alex
Index: qemu/cpu-exec.c
===
--- qemu.orig/cpu-exec.c
+++ qemu/cpu-exec.c
@@ -408,7 +408,7 @@ int cpu_exec(CPUState *env1)
 !(env-hflags  HF_INHIBIT_IRQ_MASK)) {
 int intno;
 svm_check_intercept(SVM_EXIT_INTR);
-env-interrupt_request = ~CPU_INTERRUPT_HARD;
+env-interrupt_request = ~(CPU_INTERRUPT_HARD | CPU_INTERRUPT_VIRQ);
 intno = cpu_get_pic_interrupt(env);
 if (loglevel  CPU_LOG_TB_IN_ASM) {
 fprintf(logfile, Servicing hardware INT=0x%02x\n, intno);
@@ -427,12 +427,13 @@ int cpu_exec(CPUState *env1)
  int intno;
  /* FIXME: this should respect TPR */
  env-interrupt_request = ~CPU_INTERRUPT_VIRQ;
- stl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_ctl),
-  ldl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_ctl))  ~V_IRQ_MASK);
+ svm_check_intercept(SVM_EXIT_VINTR);
  intno = ldl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_vector));
  if (loglevel  CPU_LOG_TB_IN_ASM)
  fprintf(logfile, Servicing virtual hardware INT=0x%02x\n, intno);
 	 do_interrupt(intno, 0, 0, -1, 1);
+ stl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_ctl),
+  ldl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_ctl))  ~V_IRQ_MASK);
 #if defined(__sparc__)  !defined(HOST_SOLARIS)
  tmp_T0 = 0;
 #else
Index: qemu/target-i386/helper.c
===
--- qemu.orig/target-i386/helper.c
+++ qemu/target-i386/helper.c
@@ -4120,8 +4122,9 @@ void helper_vmrun(target_ulong addr)
 if (loglevel  CPU_LOG_TB_IN_ASM)
 fprintf(logfile,  %#x %#x\n, env-exception_index, env-error_code);
 }
-if (int_ctl  V_IRQ_MASK)
+if ((int_ctl  V_IRQ_MASK) || (env-intercept  INTERCEPT_VINTR)) {
 env-interrupt_request |= CPU_INTERRUPT_VIRQ;
+}
 
 cpu_loop_exit();
 }
@@ -4283,6 +4291,13 @@ void vmexit(uint64_t exit_code, uint64_t
 ldq_phys(env-vm_vmcb + offsetof(struct vmcb, control.exit_info_2)),
 EIP);
 
+if(env-hflags  HF_INHIBIT_IRQ_MASK) {
+stl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_state), SVM_INTERRUPT_SHADOW_MASK);
+env-hflags = ~HF_INHIBIT_IRQ_MASK;
+} else {
+stl_phys(env-vm_vmcb + offsetof(struct vmcb, control.int_state), 0);
+}
+
 /* Save the VM state in the vmcb */
 SVM_SAVE_SEG(env-vm_vmcb, segs[R_ES], es);
 SVM_SAVE_SEG(env-vm_vmcb, segs[R_CS], cs);
Index: qemu/target-i386/translate.c
===
--- qemu.orig/target-i386/translate.c
+++ qemu/target-i386/translate.c
@@ -5551,8 +5551,6 @@ static target_ulong disas_insn(DisasCont
 gen_op_set_inhibit_irq();
 /* give a chance to handle pending irqs */
 gen_jmp_im(s-pc - s-cs_base);
-if (gen_svm_check_intercept(s, pc_start, SVM_EXIT_VINTR))
-break;
 gen_eob(s);
 } else {
 gen_exception(s, EXCP0D_GPF, pc_start - s-cs_base);


Re: [Qemu-devel] Is it easy to support booting off real harddrive?

2007-09-25 Thread n schembr


- Original Message 
From: naruto canada [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: Monday, September 24, 2007 4:45:46 AM
Subject: [Qemu-devel] Is it easy to support booting off real harddrive?

hi

Is it easy to support booting off real harddrive?
Thanks

--

This is the way I boot my remote systems.

# use raw disk-hda /dev/sdc
#  use image file -hda hda1.img 

qemu -kernel-kqemu   -boot c -hda /dev/sdc  -m 128 -net nic,vlan=0 -net 
tap,vlan=0,ifname=fwRed  -net nic,vlan=1 -net tap,vlan=1,ifname=fwGreen -hdb 
hd256M.img


If I need to I can move this disk to /dev/sda and boot it on real hardware.  It 
works great on linux. 







[Qemu-devel] [PATCH][MIPS] Wrap a few often used tests with unlikely()

2007-09-25 Thread Aurelien Jarno
Hi all,

The patch below wraps a few often used tests with unlikely() in
the hope of small speed improvements.

Cheers,
Aurelien

Index: target-mips/translate.c
===
RCS file: /sources/qemu/qemu/target-mips/translate.c,v
retrieving revision 1.102
diff -u -d -p -r1.102 translate.c
--- target-mips/translate.c 25 Sep 2007 14:49:47 -  1.102
+++ target-mips/translate.c 25 Sep 2007 15:41:17 -
@@ -733,19 +733,19 @@ static inline void generate_exception (D
 
 static inline void check_cp0_enabled(DisasContext *ctx)
 {
-if (!(ctx-hflags  MIPS_HFLAG_CP0))
+if (unlikely(!(ctx-hflags  MIPS_HFLAG_CP0)))
 generate_exception_err(ctx, EXCP_CpU, 1);
 }
 
 static inline void check_cp1_enabled(DisasContext *ctx)
 {
-if (!(ctx-hflags  MIPS_HFLAG_FPU))
+if (unlikely(!(ctx-hflags  MIPS_HFLAG_FPU)))
 generate_exception_err(ctx, EXCP_CpU, 1);
 }
 
 static inline void check_cp1_64bitmode(DisasContext *ctx)
 {
-if (!(ctx-hflags  MIPS_HFLAG_F64))
+if (unlikely(!(ctx-hflags  MIPS_HFLAG_F64)))
 generate_exception(ctx, EXCP_RI);
 }
 
@@ -762,7 +762,7 @@ static inline void check_cp1_64bitmode(D
  */
 void check_cp1_registers(DisasContext *ctx, int regs)
 {
-if (!(ctx-hflags  MIPS_HFLAG_F64)  (regs  1))
+if (unlikely(!(ctx-hflags  MIPS_HFLAG_F64)  (regs  1)))
 generate_exception(ctx, EXCP_RI);
 }
 
@@ -778,7 +778,7 @@ static inline void check_insn(CPUState *
CPU is not MIPS MT capable. */
 static inline void check_mips_mt(CPUState *env, DisasContext *ctx)
 {
-if (!(env-CP0_Config3  (1  CP0C3_MT)))
+if (unlikely(!(env-CP0_Config3  (1  CP0C3_MT
 generate_exception(ctx, EXCP_RI);
 }
 
@@ -786,7 +786,7 @@ static inline void check_mips_mt(CPUStat
instructions are not enabled. */
 static inline void check_mips_64(DisasContext *ctx)
 {
-if (!(ctx-hflags  MIPS_HFLAG_64))
+if (unlikely(!(ctx-hflags  MIPS_HFLAG_64)))
 generate_exception(ctx, EXCP_RI);
 }
 

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net




[Qemu-devel] [PATCH][MIPS] hflags computation cleanup

2007-09-25 Thread Aurelien Jarno
Hi all,

Currently hflags is computed at three different places of the code,
with a few minor differences.

The patch below adds a compute_hflags() function which does the same 
job. I am not sure the code is faster, but at least that makes the code
more maintainable.

It also fixes two small bugs:
 - The current code assume that writting CP0 Status only allow a 
   transition from kernel to userland. This is wrong in some rare cases
   when CP0 is accessible as a user.
 - When leaving debug mode, MIPS_HFLAG_DM should be cleared, not set.

Bye,
Aurelien


Index: target-mips/exec.h
===
RCS file: /sources/qemu/qemu/target-mips/exec.h,v
retrieving revision 1.32
diff -u -d -p -r1.32 exec.h
--- target-mips/exec.h  16 Sep 2007 21:08:03 -  1.32
+++ target-mips/exec.h  25 Sep 2007 15:40:11 -
@@ -95,6 +95,7 @@ void do_mfc0_count(void);
 void do_mtc0_entryhi(uint32_t in);
 void do_mtc0_status_debug(uint32_t old, uint32_t val);
 void do_mtc0_status_irqraise_debug(void);
+void compute_hflags(CPUState *env);
 void dump_fpu(CPUState *env);
 void fpu_dump_state(CPUState *env, FILE *f,
 int (*fpu_fprintf)(FILE *f, const char *fmt, ...),
Index: target-mips/helper.c
===
RCS file: /sources/qemu/qemu/target-mips/helper.c,v
retrieving revision 1.50
diff -u -d -p -r1.50 helper.c
--- target-mips/helper.c25 Sep 2007 14:49:46 -  1.50
+++ target-mips/helper.c25 Sep 2007 15:40:11 -
@@ -368,10 +368,8 @@ void do_interrupt (CPUState *env)
 env-CP0_DEPC = env-PC[env-current_tc];
 }
 enter_debug_mode:
-env-hflags |= MIPS_HFLAG_DM;
-env-hflags |= MIPS_HFLAG_64;
+env-hflags |= MIPS_HFLAG_DM | MIPS_HFLAG_64 | MIPS_HFLAG_CP0;
 env-hflags = ~MIPS_HFLAG_UM;
-env-hflags |= MIPS_HFLAG_CP0;
 /* EJTAG probe trap enable is not implemented... */
 if (!(env-CP0_Status  (1  CP0St_EXL)))
 env-CP0_Cause = ~(1  CP0Ca_BD);
@@ -396,9 +394,8 @@ void do_interrupt (CPUState *env)
 env-CP0_ErrorEPC = env-PC[env-current_tc];
 }
 env-CP0_Status |= (1  CP0St_ERL) | (1  CP0St_BEV);
-env-hflags |= MIPS_HFLAG_64;
+env-hflags |= MIPS_HFLAG_64 | MIPS_HFLAG_CP0;
 env-hflags = ~MIPS_HFLAG_UM;
-env-hflags |= MIPS_HFLAG_CP0;
 if (!(env-CP0_Status  (1  CP0St_EXL)))
 env-CP0_Cause = ~(1  CP0Ca_BD);
 env-PC[env-current_tc] = (int32_t)0xBFC0;
@@ -499,9 +496,8 @@ void do_interrupt (CPUState *env)
 env-CP0_Cause = ~(1  CP0Ca_BD);
 }
 env-CP0_Status |= (1  CP0St_EXL);
-env-hflags |= MIPS_HFLAG_64;
+env-hflags |= MIPS_HFLAG_64 | MIPS_HFLAG_CP0;
 env-hflags = ~MIPS_HFLAG_UM;
-env-hflags |= MIPS_HFLAG_CP0;
 }
 env-hflags = ~MIPS_HFLAG_BMASK;
 if (env-CP0_Status  (1  CP0St_BEV)) {
Index: target-mips/op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.73
diff -u -d -p -r1.73 op.c
--- target-mips/op.c25 Sep 2007 14:49:47 -  1.73
+++ target-mips/op.c25 Sep 2007 15:40:11 -
@@ -1841,30 +1841,8 @@ void op_mtc0_status (void)
 
 val = T0  mask;
 old = env-CP0_Status;
-if (!(val  (1  CP0St_EXL)) 
-!(val  (1  CP0St_ERL)) 
-!(env-hflags  MIPS_HFLAG_DM) 
-(val  (1  CP0St_UM)))
-env-hflags |= MIPS_HFLAG_UM;
-#ifdef TARGET_MIPS64
-if  ((env-hflags  MIPS_HFLAG_UM) 
-!(val  (1  CP0St_PX)) 
-!(val  (1  CP0St_UX)))
-env-hflags = ~MIPS_HFLAG_64;
-#endif
-if ((val  (1  CP0St_CU0)) || !(env-hflags  MIPS_HFLAG_UM))
-env-hflags |= MIPS_HFLAG_CP0;
-else
-env-hflags = ~MIPS_HFLAG_CP0;
-if (val  (1  CP0St_CU1))
-env-hflags |= MIPS_HFLAG_FPU;
-else
-env-hflags = ~MIPS_HFLAG_FPU;
-if (val  (1  CP0St_FR))
-env-hflags |= MIPS_HFLAG_F64;
-else
-env-hflags = ~MIPS_HFLAG_F64;
 env-CP0_Status = (env-CP0_Status  ~mask) | val;
+CALL_FROM_TB1(compute_hflags, env);
 if (loglevel  CPU_LOG_EXEC)
 CALL_FROM_TB2(do_mtc0_status_debug, old, val);
 CALL_FROM_TB1(cpu_mips_update_irq, env);
@@ -3002,21 +2980,7 @@ void op_eret (void)
 env-PC[env-current_tc] = env-CP0_EPC;
 env-CP0_Status = ~(1  CP0St_EXL);
 }
-if (!(env-CP0_Status  (1  CP0St_EXL)) 
-!(env-CP0_Status  (1  CP0St_ERL)) 
-!(env-hflags  MIPS_HFLAG_DM) 
-(env-CP0_Status  (1  CP0St_UM)))
-env-hflags |= MIPS_HFLAG_UM;
-#ifdef TARGET_MIPS64
- if ((env-hflags  MIPS_HFLAG_UM) 
-!(env-CP0_Status  (1  CP0St_PX)) 
-!(env-CP0_Status  (1  CP0St_UX)))
-env-hflags = ~MIPS_HFLAG_64;
-#endif
-if ((env-CP0_Status  (1  CP0St_CU0)) || !(env-hflags  

Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Jamie Lokier
Jocelyn Mayer wrote:
 Well, it may be needed to integrate the -cpu host option.
 But I think it's a really bad idea that running qemu without the -cpu
 option would not act the same on different host. When I want to test
 qemu with the same command line, I want it to behave exactly the same,
 whatever the host I'm running on, like any other tool. Think about gcc,
 for example, if you launch it without option, it compiles for a generic
 CPU. If you want to tune the generated code, even for the host you're
 running on, you have to use -mcpu/-march/-mtune. Using one command line
 always have gives the same result.
 Then, my opinion is that running qemu without any -cpu option should
 always use a default target.

A major feature of qemu is reproducible behaviour.  This is especially
important when resuming snapshots or booting pre-installed images for
testing things.

A major feature of kvm/kqemu is performance.  But not always
performance at the expense of reproducibility.  Sometimes you want to
use kvm/kqemu to make qemu as fast as possible while still behaving
the same with some image.

Where someone wants performance to have precedence, it's easy enough
to advise use -cpu host for that.

Where someone wants performance, but reproducibility to have
precedence, it would be more awkward to have to advise use -cpu
list,of,common,features.

I think reproducibility is something which needs to be working by
default.  This is because people make images before they decide to
move them to other hosts, and often before they would consider at all
issues about host differences, and making images is sometimes a lot of
work.  Images should be portable among hosts by default.

But, if we say that the default is a baseline CPU, and there's a -cpu
host option to maximise performance, then we have to decide what
features the baseline CPU has.  Obviously a 386 isn't very useful for
emulation any more - many OSes won't run on it.

Then, if we change our mind about the default baseline CPU, then we've
lost reproducibility for old images anyway.

That's an argument for storing the emulated CPU features in images.

If that's done, then for image portability among hosts, it is not so
important that the default CPU have only the features which
are native to every host.  Instead, the critical thing is simply that
it has only features which are either native or can be emulated on
every host.  E.g. TSC is in this category.

-- Jamie




[Qemu-devel] qemu/linux-user syscall.c

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 16:09:22

Modified files:
linux-user : syscall.c 

Log message:
Check if the hosts defines a symlinkat syscall.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.132r2=1.133




Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3

2007-09-25 Thread Avi Kivity

Jamie Lokier wrote:

Jocelyn Mayer wrote:
  

Well, it may be needed to integrate the -cpu host option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave exactly the same,
whatever the host I'm running on, like any other tool. Think about gcc,
for example, if you launch it without option, it compiles for a generic
CPU. If you want to tune the generated code, even for the host you're
running on, you have to use -mcpu/-march/-mtune. Using one command line
always have gives the same result.
Then, my opinion is that running qemu without any -cpu option should
always use a default target.



A major feature of qemu is reproducible behaviour.  This is especially
important when resuming snapshots or booting pre-installed images for
testing things.

A major feature of kvm/kqemu is performance.  But not always
performance at the expense of reproducibility.  Sometimes you want to
use kvm/kqemu to make qemu as fast as possible while still behaving
the same with some image.

Where someone wants performance to have precedence, it's easy enough
to advise use -cpu host for that.

Where someone wants performance, but reproducibility to have
precedence, it would be more awkward to have to advise use -cpu
list,of,common,features.
  


Or maybe -cpu baseline or some other neutral word.


I think reproducibility is something which needs to be working by
default.  This is because people make images before they decide to
move them to other hosts, and often before they would consider at all
issues about host differences, and making images is sometimes a lot of
work.  Images should be portable among hosts by default.

But, if we say that the default is a baseline CPU, and there's a -cpu
host option to maximise performance, then we have to decide what
features the baseline CPU has.  Obviously a 386 isn't very useful for
emulation any more - many OSes won't run on it.

  


The baseline cpu should be whatever qemu supports today.


Then, if we change our mind about the default baseline CPU, then we've
lost reproducibility for old images anyway.

That's an argument for storing the emulated CPU features in images.
  


That's another thread -- I want memory size and network configuration in 
there too :)



If that's done, then for image portability among hosts, it is not so
important that the default CPU have only the features which
are native to every host.  Instead, the critical thing is simply that
it has only features which are either native or can be emulated on
every host.  E.g. TSC is in this category.
  


Qemu is used to support three different user classes which have 
different requirements. Developers want reproducibility and control, so 
-cpu baseline should be the default for them. Home users want speed to 
run Windows or test distros, so -cpu host and kvm should be the default 
for them. Managed deployments want something in between, so they'd 
specify -cpu feature,feature and won't care about the default.


We can make it a ./configure option. I suspect distros will want to set 
-cpu host as default as their users primarily care about speed.


--
Any sufficiently difficult bug is indistinguishable from a feature.





[Qemu-devel] qemu hw/mips_timer.c target-mips/exec.h target-...

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 16:53:16

Modified files:
hw : mips_timer.c 
target-mips: exec.h op.c op_helper.c 

Log message:
Timer start/stop implementation, by Aurelien Jarno.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_timer.c?cvsroot=qemur1=1.7r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.32r2=1.33
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.73r2=1.74
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.59r2=1.60




[Qemu-devel] -vmwarevga + -soundhw es1370 = crash

2007-09-25 Thread Rick Vernam
Regarding this patch, adding VMware's VGA SVGA II emulation: 
http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00116.html

I just decided to try it today, but did not get very good results.
I tried with User+Kernel kqemu, just user kqemu  no kqemu
with -soundhw es1370  -vmwarevga it crashes:

[EMAIL PROTECTED] ~ $ 
qemu-system-x86_64 -kernel-kqemu -hda /home/rick/docs/.qemu/wxp.qc2 -m 
192 -net nic -net 
tap,script=/etc/qemu-ifup -localtime -vmwarevga -usb -soundhw 
es1370, -snapshot
qemu: hardware error: register_ioport_write: invalid opaque
CPU #0:
EAX=0007 EBX= ECX=0004 EDX=0cfc
ESI=0cfc EDI=806db210 EBP=faf7f7a8 ESP=faf7f794
EIP=806d691c EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0023   00cff300
CS =0008   00cffb00
SS =0010   00cff300
DS =0023   00cff300
FS =0030 ffdff000 1fff ff40f3df
GS =   
LDT=   8000
TR =0028 80042000 20ab 8900
GDT= 8003f000 03ff
IDT= 8003f400 07ff
CR0=e0010031 CR2=e147 CR3=002fa000 CR4=06f8
FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
Aborted




Re: [Qemu-devel] -vmwarevga + -soundhw es1370 = crash

2007-09-25 Thread Rick Vernam
sorry - accidentally sent before I finished the mail...
On Tuesday 25 September 2007 12:06:28 pm Rick Vernam wrote:
 Regarding this patch, adding VMware's VGA SVGA II emulation:
 http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00116.html

 I just decided to try it today, but did not get very good results.
 I tried with User+Kernel kqemu, just user kqemu  no kqemu
 with -soundhw es1370  -vmwarevga it crashes:

 [EMAIL PROTECTED] ~ $
 qemu-system-x86_64 -kernel-kqemu -hda /home/rick/docs/.qemu/wxp.qc2 -m
 192 -net nic -net
 tap,script=/etc/qemu-ifup -localtime -vmwarevga -usb -soundhw
 es1370, -snapshot
 qemu: hardware error: register_ioport_write: invalid opaque
 CPU #0:
 EAX=0007 EBX= ECX=0004 EDX=0cfc
 ESI=0cfc EDI=806db210 EBP=faf7f7a8 ESP=faf7f794
 EIP=806d691c EFL=00010202 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
 ES =0023   00cff300
 CS =0008   00cffb00
 SS =0010   00cff300
 DS =0023   00cff300
 FS =0030 ffdff000 1fff ff40f3df
 GS =   
 LDT=   8000
 TR =0028 80042000 20ab 8900
 GDT= 8003f000 03ff
 IDT= 8003f400 07ff
 CR0=e0010031 CR2=e147 CR3=002fa000 CR4=06f8
 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80
 FPR0=  FPR1= 
 FPR2=  FPR3= 
 FPR4=  FPR5= 
 FPR6=  FPR7= 
 XMM00=
 XMM01=
 XMM02=
 XMM03=
 XMM04=
 XMM05=
 XMM06=
 XMM07= Aborted


Host CPU is AMD Athlon(tm) 64 Processor 3700+
Host kernel is 2.6.22-gentoo-r2
Guest OS is WinXP
Qemu is CVS from a few weeks back, kqemu is 1.3.0pre11




[Qemu-devel] qemu monitor.c

2007-09-25 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1  07/09/25 17:28:43

Modified files:
.  : monitor.c 

Log message:
 Fix monitor expressions

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemur1=1.82r2=1.83




[Qemu-devel] qemu elf_ops.h

2007-09-25 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1  07/09/25 17:30:09

Modified files:
.  : elf_ops.h 

Log message:
 Remove the target dependency introduced by previous patch

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemur1=1.9r2=1.10




Re: [Qemu-devel] qemu/target-sparc exec.h op.c op_helper.c op_me...

2007-09-25 Thread Andreas Färber


Am 23.09.2007 um 01:11 schrieb Aurelien Jarno:


Aurelien Jarno a écrit :
Thanks, that's helpful, it looks like the lduba instructions  
is not

working correctly in your case. Now I have to find why.

I don't really understand, because that is the part of the code (at
least from the op point of view) that is almost unchanged.  
Looking at

the code again and again I can't see any problem.


PS: I don't know if I will be able to get internet access in the  
next 4

days.


Just a short note that Blue Swirl's added break statements did not  
change the results previously posted.







[Qemu-devel] qemu/linux-user syscall.c

2007-09-25 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/09/25 17:50:37

Modified files:
linux-user : syscall.c 

Log message:
linux-user utimensat() syscall, by Thayne Harbaugh.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.133r2=1.134




Re: [Qemu-devel] -usbdevice tablet with Fedora-6 64bit guest

2007-09-25 Thread Daniel P. Berrange
On Tue, Sep 25, 2007 at 02:03:56PM +0200, Dan Kenigsberg wrote:
 On Thu, Sep 20, 2007 at 02:41:32PM +0100, Daniel P. Berrange wrote:
  On Thu, Sep 20, 2007 at 03:36:26PM +0200, Dan Kenigsberg wrote:
   Hi,
   
   I saw that using the tablet with Linux guest is possible
   http://thread.gmane.org/gmane.comp.emulators.qemu/11516
   yet I fail to do that.
   
   I managed to compile, configure and load the evtouch X module, but still
   there is no movement of the mouse (after I disabled the default X
   pointer). I attach my Xorg.0.log for the joy of the readership.
  
  Don't use the evtouch X module. Use the regular 'evdev' module.
  
  Dan.
 
 Dan, thanks for this info. However, my problem begins earlier than in X
 and using evdev instead of evtouch does not solve it.
 
 It seems that some Linux guests have problems communicating with the
 tablet device. The most reproducible behavior that I noticed is when
 FC-6 starts: gpm senses the tablet, but only until haldaemon starts.
 After that, I cannot obtain any mouse event (even after stopping
 haldaemon).

By an unfortunate co-incidence I've just hit a similar problem myself. It
turns out QEMU mouse handling is more complex than I realized. QEMU can
export several different input devices to a guest OS, PS/2 mouse, VMWare
mouse, USB mouse, USB EvTouch tablet, USB Wacom tablet. Only one of these
devices will be fed mouse events from the host OS though at any time. The
default is that the most recently 'activated' mouse will get the events.
This starts off being the PS/2 mouse. Certain actions in the guest OS may
cause one or more of the other input devices to activate itself, and thus
claiming control of all input events from the host.

You can see what mice are configured at any time from the QEMU monitor by
typing 'info mice'. The active one has an * next to it.  What I suspect
is happening in your case is that you've configured the USB tablet, but
during initial boot only the PS/2 mouse is activated  GPM is actually
responding to events from the PS/2 mouse no the tablet. Then during boot 
something in HAL (or perhaps X itself) causes the USB tablet to become
active  thus the PS/2 mouse stops getting events. But then it sounds
like neither GPM or X are configured to use the USB tablet either, so
you end up with no movement at all.

So I guess it is probably a matter of suitably configuring Xorg to use
the USB tablet, though I can't remember exact syntax for Fedora Core 6,
in Fedora 7 I have successfully used:

Section InputDevice
  Name Mouse0
  Driver evdev
  Option Name QEMU 0.8.2 QEMU USB Tablet
  Option Mode Absolute
EndSection

NB, make sure 'Mouse0' is referenced as the CorePointer in the ServerLayout
section of the config. Also the 'Name' value varies acording to what QEMU
version you have[1] - check /proc/bus/input/devices for exact name seen
by the guest OS

Dan.

[1] Really rather unfortunate - if the QEMU version number were removed 
from the printable USB device name exposed to guests the config for
Xorg would be stable across QEMU version.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-   Perl modules: http://search.cpan.org/~danberr/  -=|
|=-   Projects: http://freshmeat.net/~danielpb/   -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|