[Qemu-devel] kqemu version 1.3.0pre5

[Qemu-devel] kqemu version 1.3.0pre5

[Fabrice Bellard]

Hi,

I just released a new version of kqemu which fixes some recently 
discovered issues. The fixes are the following:

- Support for guest Linux kernels compiled with gcc >= 3.3

- x86_64 host support is working again (only i386 on x86_64 full 
virtualization has been tested, x86_64 on x86_64 is implemented but not 
tested yet).

- Workaround for full virtualization on Windows host (more tests needed).

The documentation (http://bellard.org/qemu/kqemu1-doc.html) gives more 
information about the new "full virtualization" mode.

Fabrice.

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Pascal Terjan]

On 3/27/06, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> I just released a new version of kqemu which fixes some recently
> discovered issues. The fixes are the following:
>
> - Support for guest Linux kernels compiled with gcc >= 3.3

Hello,
I tried the Mandriva boot.iso and it now boots fine, thanks !

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Brad Campbell]

Fabrice Bellard wrote:
> Hi,
> 
> I just released a new version of kqemu which fixes some recently 
> discovered issues. The fixes are the following:
> 
> - Support for guest Linux kernels compiled with gcc >= 3.3
> 

Tested with 2.4.26 & 2.6.16 - gcc-3.2, gcc-3.3, gcc-3.4 & gcc-4.0.2
Win2k-SP3, Win2k-SP4, WinXP-SP1, WinXP-SP2
AthlonXP, Sempron & PIII-M

and all combinations of.

Nice work :)

-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu version 1.3.0pre5

[sofar]

On Tue, 28 Mar 2006 12:26:37 +0400, Brad Campbell <brad@wasp.net.au> wrote:
> Fabrice Bellard wrote:
>> Hi,
>>
>> I just released a new version of kqemu which fixes some recently
>> discovered issues. The fixes are the following:
>>
>> - Support for guest Linux kernels compiled with gcc >= 3.3
>>
> 
> Tested with 2.4.26 & 2.6.16 - gcc-3.2, gcc-3.3, gcc-3.4 & gcc-4.0.2
> Win2k-SP3, Win2k-SP4, WinXP-SP1, WinXP-SP2
> AthlonXP, Sempron & PIII-M
> 
> and all combinations of.
> 
> Nice work :)
> 

thanks for putting in the MODULE_LICENSE folks!

Auke

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Kazu]

Sent: Tuesday, March 28, 2006 6:30 AM Fabrice Bellard wrote:

> Hi,
>
> I just released a new version of kqemu which fixes some recently
> discovered issues. The fixes are the following:
>
> - Support for guest Linux kernels compiled with gcc >= 3.3
>
> - x86_64 host support is working again (only i386 on x86_64 full
> virtualization has been tested, x86_64 on x86_64 is implemented but not
> tested yet).
>
> - Workaround for full virtualization on Windows host (more tests needed).
>

I tested Linux guest/WinXP host but the host OS crashed.

Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower
than -no-kqemu. Why ?

Regards,
Kazu

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Brad Campbell]

Kazu wrote:

> I tested Linux guest/WinXP host but the host OS crashed.

I believe -kernel-kqemu is still somewhat experimental on Windows host.

> Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower
> than -no-kqemu. Why ?

Have you got your tmpfs set up correctly so qemu can place its memory swap file in a ramdisk rather 
than on disk?

/dev/hda1             4.6G  3.1G  1.4G  69% /
tmpfs                 506M     0  506M   0% /dev/shm
/dev/hda2             4.6G  4.5G  103M  98% /home
/dev/hda6              44G   44G  424K 100% /tracks
none                  768M  137M  632M  18% /tmp  <-- not sure why it says none.. it's tmpfs

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Marco Matthies]

Brad Campbell wrote:
> none                  768M  137M  632M  18% /tmp  <-- not sure why it 
> says none.. it's tmpfs

change the none to tmpfs in /etc/fstab. normally the mount point goes 
there, but tmpfs (and proc, for example) don't have a mount point so you 
can put anything there.

marco

Re: [Qemu-devel] kqemu version 1.3.0pre5

[andrzej zaborowski]

On 28/03/06, Marco Matthies <marco-ml@gmx.net> wrote:
> Brad Campbell wrote:
> > none                  768M  137M  632M  18% /tmp  <-- not sure why it
> > says none.. it's tmpfs
>
> change the none to tmpfs in /etc/fstab. normally the mount point goes
> there, but tmpfs (and proc, for example) don't have a mount point so you
> can put anything there.
You mean they don't have a device node. They do have mountpoints.

Regarding crashes of the host OS, that might have nothing to do with
QEMU. Ms Windows is known to be an "experimental" OS in general (by
experimental I mean that it crashes a lot) :-)
Normal Operating Systems don't crash no matter what program they are running.
>
> marco
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Paul Brook]

> Normal Operating Systems don't crash no matter what program they are
> running.

Except that kqemu is a kernel module (or windows equivalent). As such it is 
effectively part of the OS, and can easily crash the whole machine.

Paul

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Bruno Abinader]

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

Works fine on my computer too!

OS: Ubuntu 5.10 (Breezy Badger)
CPU: Athlon XP 2000+ (with kernel 2.6.12-10-k7)
Using latest CVS version of QEMU with some USB patches from
http://gnome.dnsalias.net/patches/

On 3/28/06, Paul Brook <paul@codesourcery.com> wrote:
>
> > Normal Operating Systems don't crash no matter what program they are
> > running.
>
> Except that kqemu is a kernel module (or windows equivalent). As such it
> is
> effectively part of the OS, and can easily crash the whole machine.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>



--
Bruno de Oliveira Abinader
10LE/INdT

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

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Brad Campbell]

Paul Brook wrote:
>> Normal Operating Systems don't crash no matter what program they are
>> running.
> 
> Except that kqemu is a kernel module (or windows equivalent). As such it is 
> effectively part of the OS, and can easily crash the whole machine.

Yes indeed.

I'm actually quite impressed. I've crashed my guests loads, I've crashed qemu loads and yet I've 
never managed to leave kqemu in a state that compromised the system integrity.... I'm not betting my 
life it won't happen, but thus far I've been quite lucky I guess.. (And I have done some severely 
stupid things to blow up both qemu and the guests so far)

All bets are off for a Windows host though. I'm sure it's much easier to write a module that does 
what kqemu does when you a) have a good understanding of what goes on under the hood, and b) have 
the source to verify this.. unlike writing a Windows system module.

Kudos to the guys who put that together and their progress thus far.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Jernej Simončič]

On Tuesday, March 28, 2006, 14:27:48, andrzej zaborowski wrote:

> Normal Operating Systems don't crash no matter what program they are running.

That only applies to user-mode programs that don't make calls to device
drivers. Kqemu is basically a device driver which runs in kernel space, and
a crash in there will bring down whole system.

-- 
< Jernej Simončič ><><><><>< http://deepthought.ena.si/ >

The first pull on the cord ALWAYS sends the drapes in the wrong direction.
       -- Boyle's Other Law

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Kazu]

Sent: Tuesday, March 28, 2006 8:50 PM Brad Campbell wrote:


> Kazu wrote:
>
>> I tested Linux guest/WinXP host but the host OS crashed.
>
> I believe -kernel-kqemu is still somewhat experimental on Windows host.
>
>> Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower
>> than -no-kqemu. Why ?
>
> Have you got your tmpfs set up correctly so qemu can place its memory swap
file in a ramdisk rather
> than on disk?
>

I used tmpfs but the result is the same. Thanks, anyway.

Regards,
Kazu

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Ed Swierk]

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

I'm still getting a kernel panic running a Linux guest kernel with
-kernel-qemu. I'm using kqemu-1.3.0pre5 and
qemu-snapshot-2006-03-27_23.

The guest kernel is a precompiled Fedora Core 4 kernel, version
2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.

Any hints for how to track this problem down?

--Ed

[-- Attachment #2: crash.txt --]
[-- Type: text/plain, Size: 5252 bytes --]

Linux version 2.6.14-1.1656_FC4 (bhcompile@tweety.build.redhat.com) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Thu Jan 5 22:13:22 EST 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
0MB HIGHMEM available.
256MB LOWMEM available.
Using x86 segment limits to approximate NX protection
DMI not present.
ACPI: Unable to locate RSDP
Allocating PCI resources starting at 20000000 (gap: 10000000:f0000000)
Built 1 zonelists
Kernel command line: bootdev=hda1 bootnod=b,3,1 boottype=vfat bootdir=/swi/Aros-1.3.0 console=ttyS0 selinux=0
Initializing CPU#0
CPU 0 irqstacks, hard=c03f3000 soft=c03f2000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3000.676 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 254412k/262144k available (2099k kernel code, 7072k reserved, 718k data, 172k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6043.49 BogoMIPS (lpj=12086981)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) D CPU 3.00GHz stepping 04
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
checking if image is initramfs... it is
Freeing initrd memory: 1232k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf9ce0, last bus=0
PCI: Using configuration type 1
ACPI: Subsystem revision 20050916
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX/ICH [8086/7000] at 0000:00:01.0
PCI: BIOS reporting unknown device 01:00
PCI: BIOS reporting unknown device 01:00
PCI: BIOS reporting unknown device 01:00
PCI: BIOS reporting unknown device 01:00
PCI: BIOS reporting unknown device 01:00
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
audit: initializing netlink socket (disabled)
audit(1143569137.708:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 86D1D7472B6BE898
- User ID: Red Hat, Inc. (Kernel Module GPG key)
PCI: PIIX3: Enabling Passive Release on 0000:00:01.0
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled
invalid operand: 0000 [#1]
Modules linked in:
CPU:    0
EIP:    0060:[<c0101147>]    Not tainted VLI
EFLAGS: 00010246   (2.6.14-1.1656_FC4)
EIP is at mwait_idle+0x2f/0x41
eax: c03c1008   ebx: c03c1008   ecx: 00000000   edx: 00000000
esi: c03c1000   edi: 00000010   ebp: 00000000   esp: c03c1fc4
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c03c1000 task=c0361c60)
Stack: 00000800 c03c1000 c0113749 c03c1000 00000800 00099100 c03bd800 00461007
       c01010a6 c03c270a 0000004c c03c22e9 00000000 c03f4e60 c0100199
Call Trace:
 [<c0113749>] apm_cpu_idle+0x5e/0x157
 [<c01010a6>] cpu_idle+0x34/0x4c
 [<c03c270a>] start_kernel+0x15f/0x1b9
 [<c03c22e9>] unknown_bootoption+0x0/0x1b6
Code: 00 f0 ff ff 21 e2 8b 42 08 a8 08 75 2d 0f ba 6a 08 10 89 d6 8d 5a 08 31 c9 eb 0c 89 c8 0f 01 c9 8b 46 08 a8 08 75 0e 89 d8 89 ca <0f> 01 c8 8b 46 08 a8 08 74 e6 0f ba 76 08 10 5b 5e c3 83 ec 04
 <0>Kernel panic - not syncing: Attempted to kill the idle task!
 [<c011a858>] panic+0x45/0x1b4
 [<c011baa0>] profile_task_exit+0x30/0x43
 [<c011d610>] do_exit+0x375/0x3b8
 [<c01037e7>] do_divide_error+0x0/0xa8
 [<c0103977>] do_invalid_op+0x0/0xab
 [<c0103a19>] do_invalid_op+0xa2/0xab
 [<c0101147>] mwait_idle+0x2f/0x41
 [<c0236179>] serial8250_console_write+0x0/0x1ec
 [<c011aefe>] __call_console_drivers+0x38/0x44
 [<c0117036>] wake_up_new_task+0xe4/0x184
 [<c011a352>] do_fork+0xd6/0x1e9
 [<c011b3d5>] vprintk+0x1e7/0x2a9
 [<c011b3d5>] vprintk+0x1e7/0x2a9
 [<c01030cb>] error_code+0x4f/0x54
 [<c030007b>] xfrm_get_byname+0x83/0x9a
 [<c0101147>] mwait_idle+0x2f/0x41
 [<c0113749>] apm_cpu_idle+0x5e/0x157
 [<c01010a6>] cpu_idle+0x34/0x4c
 [<c03c270a>] start_kernel+0x15f/0x1b9
 [<c03c22e9>] unknown_bootoption+0x0/0x1b6

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Brad Campbell]

Ed Swierk wrote:
> I'm still getting a kernel panic running a Linux guest kernel with
> -kernel-qemu. I'm using kqemu-1.3.0pre5 and
> qemu-snapshot-2006-03-27_23.
> 
> The guest kernel is a precompiled Fedora Core 4 kernel, version
> 2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.
> 
> Any hints for how to track this problem down?

I was getting an almost _identical_ error on my laptop.. turned out I had forgot to copy the latest 
and greatest bios *.bin files to /usr/local/share/qemu

Updated the bios from the cvs source dir and it's all been peachy since..

Hope yours is similar..

You do need to be running the absolute latest cvs really for this to work properly..
My desktop was ok, but my laptop was a couple of days worth of commits out of date and *boom*

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Jens Axboe]

On Tue, Mar 28 2006, Ed Swierk wrote:
> I'm still getting a kernel panic running a Linux guest kernel with
> -kernel-qemu. I'm using kqemu-1.3.0pre5 and
> qemu-snapshot-2006-03-27_23.
> 
> The guest kernel is a precompiled Fedora Core 4 kernel, version
> 2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.
> 
> Any hints for how to track this problem down?

[snip]

> monitor/mwait feature present.
> using mwait in idle threads.

[snip]

> invalid operand: 0000 [#1]
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c0101147>]    Not tainted VLI
> EFLAGS: 00010246   (2.6.14-1.1656_FC4)
> EIP is at mwait_idle+0x2f/0x41

I don't think qemu supports PNI, which includes the monitor/mwait
additions. I wonder why Linux detects that. You can probably get around
it for now by either passing idle=poll as a boot parameter, or compile
your kernel for plain i586 for instance.

-- 
Jens Axboe

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Ed Swierk]

On 3/28/06, Jens Axboe <qemu@kernel.dk> wrote:
> > monitor/mwait feature present.
> > using mwait in idle threads.
>
> [snip]
>
> > invalid operand: 0000 [#1]
> > Modules linked in:
> > CPU:    0
> > EIP:    0060:[<c0101147>]    Not tainted VLI
> > EFLAGS: 00010246   (2.6.14-1.1656_FC4)
> > EIP is at mwait_idle+0x2f/0x41
>
> I don't think qemu supports PNI, which includes the monitor/mwait
> additions. I wonder why Linux detects that. You can probably get around
> it for now by either passing idle=poll as a boot parameter, or compile
> your kernel for plain i586 for instance.

It seems that with -kernel-kqemu, the guest kernel is seeing the CPUID
of the host machine rather than the one normally generated by qemu.

The workarounds you suggest do work--thanks for your help. However,
ideally kqemu would trap the CPUID instruction and mask the feature
bits for unsupported CPU features.

--Ed

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Fabrice Bellard]

Ed Swierk wrote:
> On 3/28/06, Jens Axboe <qemu@kernel.dk> wrote:
> 
>>>monitor/mwait feature present.
>>>using mwait in idle threads.
>>
>>[snip]
>>
>>
>>>invalid operand: 0000 [#1]
>>>Modules linked in:
>>>CPU:    0
>>>EIP:    0060:[<c0101147>]    Not tainted VLI
>>>EFLAGS: 00010246   (2.6.14-1.1656_FC4)
>>>EIP is at mwait_idle+0x2f/0x41
>>
>>I don't think qemu supports PNI, which includes the monitor/mwait
>>additions. I wonder why Linux detects that. You can probably get around
>>it for now by either passing idle=poll as a boot parameter, or compile
>>your kernel for plain i586 for instance.
> 
> 
> It seems that with -kernel-kqemu, the guest kernel is seeing the CPUID
> of the host machine rather than the one normally generated by qemu.
> 
> The workarounds you suggest do work--thanks for your help. However,
> ideally kqemu would trap the CPUID instruction and mask the feature
> bits for unsupported CPU features.

The problem is that it is not possible to trap on the CPUID instruction 
:-( So the only possible patch is to support PNI in QEMU. For 
monitor/mwait for example, doing nops should suffice...

Fabrice.

[Qemu-devel][PATCH] add PNI user instructions

[Joachim Henke]

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

I've posted a patch that adds SSE3 instruction emulation to QEMU some  
weeks ago, but it accidentally contained some silly changes. Sorry  
for that.

I'm currently very short on time, so I've just attached a fixed  
version. To complete PNI, both the monitor and the mwait instruction,  
and also the MON CPUID flag must be added.

Fabrice Bellard wrote:
> The problem is that it is not possible to trap on the CPUID  
> instruction :-( So the only possible patch is to support PNI in  
> QEMU. For monitor/mwait for example, doing nops should suffice...
>
> Fabrice.

-- 
Joachim Henke
http://he-jo.net/


[-- Attachment #2: sse3-2006-03-28.diff --]
[-- Type: application/octet-stream, Size: 7980 bytes --]

--- target-i386/cpu.h
+++ target-i386/cpu.h
@@ -265,7 +265,7 @@
 #define CPUID_SSE  (1 << 25)
 #define CPUID_SSE2 (1 << 26)
 
-#define CPUID_EXT_SS3      (1 << 0)
+#define CPUID_EXT_SSE3     (1 << 0)
 #define CPUID_EXT_MONITOR  (1 << 3)
 #define CPUID_EXT_CX16     (1 << 13)
 

--- target-i386/exec.h
+++ target-i386/exec.h
@@ -260,6 +260,8 @@
 /* use long double functions */
 #define floatx_to_int32 floatx80_to_int32
 #define floatx_to_int64 floatx80_to_int64
+#define floatx_to_int32_round_to_zero floatx80_to_int32_round_to_zero
+#define floatx_to_int64_round_to_zero floatx80_to_int64_round_to_zero
 #define floatx_abs floatx80_abs
 #define floatx_chs floatx80_chs
 #define floatx_round_to_int floatx80_round_to_int
@@ -278,6 +280,8 @@
 #else
 #define floatx_to_int32 float64_to_int32
 #define floatx_to_int64 float64_to_int64
+#define floatx_to_int32_round_to_zero float64_to_int32_round_to_zero
+#define floatx_to_int64_round_to_zero float64_to_int64_round_to_zero
 #define floatx_abs float64_abs
 #define floatx_chs float64_chs
 #define floatx_round_to_int float64_round_to_int

--- target-i386/helper2.c
+++ target-i386/helper2.c
@@ -103,13 +103,12 @@
 #endif
         env->cpuid_level = 2;
         env->cpuid_version = (family << 8) | (model << 4) | stepping;
-        env->cpuid_features = (CPUID_FP87 | CPUID_DE | CPUID_PSE |
-                               CPUID_TSC | CPUID_MSR | CPUID_MCE |
-                               CPUID_CX8 | CPUID_PGE | CPUID_CMOV |
-                               CPUID_PAT);
+        env->cpuid_features = CPUID_FP87 | CPUID_DE | CPUID_PSE | CPUID_TSC |
+                              CPUID_MSR | CPUID_PAE | CPUID_MCE | CPUID_CX8 |
+                              CPUID_SEP | CPUID_PGE | CPUID_CMOV | CPUID_PAT |
+                              CPUID_MMX | CPUID_FXSR | CPUID_SSE | CPUID_SSE2;
+        env->cpuid_ext_features = CPUID_EXT_SSE3;
         env->pat = 0x0007040600070406ULL;
-        env->cpuid_ext_features = 0;
-        env->cpuid_features |= CPUID_FXSR | CPUID_MMX | CPUID_SSE | CPUID_SSE2 | CPUID_PAE | CPUID_SEP;
         env->cpuid_xlevel = 0;
         {
             const char *model_id = "QEMU Virtual CPU version " QEMU_VERSION;

--- target-i386/op.c
+++ target-i386/op.c
@@ -1911,6 +1911,53 @@
     FORCE_RET();
 }
 
+void OPPROTO op_fistt_ST0_A0(void)
+{
+#if defined(__sparc__) && !defined(__sparc_v9__)
+    register CPU86_LDouble d asm("o0");
+#else
+    CPU86_LDouble d;
+#endif
+    int val;
+
+    d = ST0;
+    val = floatx_to_int32_round_to_zero(d, &env->fp_status);
+    if (val != (int16_t)val)
+        val = -32768;
+    stw(A0, val);
+    FORCE_RET();
+}
+
+void OPPROTO op_fisttl_ST0_A0(void)
+{
+#if defined(__sparc__) && !defined(__sparc_v9__)
+    register CPU86_LDouble d asm("o0");
+#else
+    CPU86_LDouble d;
+#endif
+    int val;
+
+    d = ST0;
+    val = floatx_to_int32_round_to_zero(d, &env->fp_status);
+    stl(A0, val);
+    FORCE_RET();
+}
+
+void OPPROTO op_fisttll_ST0_A0(void)
+{
+#if defined(__sparc__) && !defined(__sparc_v9__)
+    register CPU86_LDouble d asm("o0");
+#else
+    CPU86_LDouble d;
+#endif
+    int64_t val;
+
+    d = ST0;
+    val = floatx_to_int64_round_to_zero(d, &env->fp_status);
+    stq(A0, val);
+    FORCE_RET();
+}
+
 void OPPROTO op_fbld_ST0_A0(void)
 {
     helper_fbld_ST0_A0();

--- target-i386/translate.c
+++ target-i386/translate.c
@@ -2334,7 +2334,7 @@
     /* pure SSE operations */
     [0x10] = { SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL }, /* movups, movupd, movss, movsd */
     [0x11] = { SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL }, /* movups, movupd, movss, movsd */
-    [0x12] = { SSE_SPECIAL, SSE_SPECIAL },  /* movlps, movlpd */
+    [0x12] = { SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL, SSE_SPECIAL }, /* movlps, movlpd, movsldup, movddup */
     [0x13] = { SSE_SPECIAL, SSE_SPECIAL },  /* movlps, movlpd */
     [0x14] = { gen_op_punpckldq_xmm, gen_op_punpcklqdq_xmm },
     [0x15] = { gen_op_punpckhdq_xmm, gen_op_punpckhqdq_xmm },
@@ -2436,7 +2436,7 @@
     [0xed] = MMX_OP2(paddsw),
     [0xee] = MMX_OP2(pmaxsw),
     [0xef] = MMX_OP2(pxor),
-    [0xf0] = { NULL, NULL, NULL, SSE_SPECIAL }, /* lddqu (PNI) */
+    [0xf0] = { NULL, NULL, NULL, SSE_SPECIAL }, /* lddqu */
     [0xf1] = MMX_OP2(psllw),
     [0xf2] = MMX_OP2(pslld),
     [0xf3] = MMX_OP2(psllq),
@@ -2563,8 +2563,8 @@
         case 0x1e7: /* movntdq */
         case 0x02b: /* movntps */
         case 0x12b: /* movntps */
-        case 0x2f0: /* lddqu */
-            if (mod == 3) 
+        case 0x3f0: /* lddqu */
+            if (mod == 3)
                 goto illegal_op;
             gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
             gen_sto_env_A0[s->mem_index >> 2](offsetof(CPUX86State,xmm_regs[reg]));
@@ -2642,6 +2642,34 @@
                             offsetof(CPUX86State,xmm_regs[rm].XMM_Q(1)));
             }
             break;
+        case 0x212: /* movsldup */
+            if (mod != 3) {
+                gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
+                gen_ldo_env_A0[s->mem_index >> 2](offsetof(CPUX86State,xmm_regs[reg]));
+            } else {
+                rm = (modrm & 7) | REX_B(s);
+                gen_op_movl(offsetof(CPUX86State,xmm_regs[reg].XMM_L(0)),
+                            offsetof(CPUX86State,xmm_regs[rm].XMM_L(0)));
+                gen_op_movl(offsetof(CPUX86State,xmm_regs[reg].XMM_L(2)),
+                            offsetof(CPUX86State,xmm_regs[rm].XMM_L(2)));
+            }
+            gen_op_movl(offsetof(CPUX86State,xmm_regs[reg].XMM_L(1)),
+                        offsetof(CPUX86State,xmm_regs[reg].XMM_L(0)));
+            gen_op_movl(offsetof(CPUX86State,xmm_regs[reg].XMM_L(3)),
+                        offsetof(CPUX86State,xmm_regs[reg].XMM_L(2)));
+            break;
+        case 0x312: /* movddup */
+            if (mod != 3) {
+                gen_lea_modrm(s, modrm, &reg_addr, &offset_addr);
+                gen_ldq_env_A0[s->mem_index >> 2](offsetof(CPUX86State,xmm_regs[reg].XMM_Q(0)));
+            } else {
+                rm = (modrm & 7) | REX_B(s);
+                gen_op_movq(offsetof(CPUX86State,xmm_regs[reg].XMM_Q(0)),
+                            offsetof(CPUX86State,xmm_regs[rm].XMM_Q(0)));
+            }
+            gen_op_movq(offsetof(CPUX86State,xmm_regs[reg].XMM_Q(1)),
+                        offsetof(CPUX86State,xmm_regs[rm].XMM_Q(0)));
+            break;
         case 0x016: /* movhps */
         case 0x116: /* movhpd */
             if (mod != 3) {
@@ -4278,16 +4306,9 @@
             case 0x08: /* flds */
             case 0x0a: /* fsts */
             case 0x0b: /* fstps */
-            case 0x18: /* fildl */
-            case 0x1a: /* fistl */
-            case 0x1b: /* fistpl */
-            case 0x28: /* fldl */
-            case 0x2a: /* fstl */
-            case 0x2b: /* fstpl */
-            case 0x38: /* filds */
-            case 0x3a: /* fists */
-            case 0x3b: /* fistps */
-                
+            case 0x18 ... 0x1b: /* fildl, fisttpl, fistl, fistpl */
+            case 0x28 ... 0x2b: /* fldl, fisttpll, fstl, fstpl */
+            case 0x38 ... 0x3b: /* filds, fisttps, fists, fistps */
                 switch(op & 7) {
                 case 0:
                     switch(op >> 4) {
@@ -4306,6 +4327,20 @@
                         break;
                     }
                     break;
+                case 1:
+                    switch(op >> 4) {
+                    case 1:
+                        gen_op_fisttl_ST0_A0();
+                        break;
+                    case 2:
+                        gen_op_fisttll_ST0_A0();
+                        break;
+                    case 3:
+                    default:
+                        gen_op_fistt_ST0_A0();
+                    }
+                    gen_op_fpop();
+                    break;
                 default:
                     switch(op >> 4) {
                     case 0:

[-- Attachment #3: Type: text/plain, Size: 29 bytes --]

--Apple-Mail-11--16704747-

Re: [Qemu-devel] kqemu version 1.3.0pre5

[Christian MICHON]

I tried various guests today on winXP host.

* No crash and good speed for std kqemu (no kernel-kqemu)
* Crash of winXP host systematically on all guests (linux + ms)

It's hard to debug what is the problem. The only thing I have the
time to see is a BSOD (blue screen of d**th) and the error
message, informative ?

"TRAP_CAUSE_UNKNOWN"

Good job overall :) Kudos to the developpers.

Maybe we can make it a bartpe plugin one day, automatically
started with kqemu on ? That would be nice to promote
qemu virtualization features...

On 3/27/06, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
>
> I just released a new version of kqemu which fixes some recently
> discovered issues. The fixes are the following:
>
> - Workaround for full virtualization on Windows host (more tests needed).
>

--
Christian

Re: [Qemu-devel] kqemu version 1.3.0pre5

[denis.scheidt]

Hello,

I have the same issues as Christian : I'm unable to get -kernel-kqemu option to
work.

My configuration :

Host : Windows XPpro SP2 on Intel P4HT

QEMU : 0.8.0 latest CVS version.
qemu.exe process' affinity set to second 'CPU' (with ImageCfg, but the result is
the same if set with ProcExp or with TaskMgr)

Guests :
* Windows 2000 SP4 : freezes just after loading splash screen...
* Ubuntu 5.10      : gives a kernel panic...

Procexp shows about 100% CPU usage in kernel mode... but it's possible to switch
to QEMU console and 'q'uit.

Everything works great when I don't use kernel-kqemu...

Am I missing something ?

[Qemu-devel] qemu-0.8.0 and vde-1.5.9 question

[Ishwar Rattan]

The system is Kanotix-2005-4
Qemu-0.8.0
Vde-1.5.9

I setup the bridge and add interface tun0 to the bridge
(have done it before correctly)

but

/usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=54:52:00:12:34:62

reports error:
qemu: invalid option -- '-tun-fd'
qemu exited: vdeqemu quits

I seem to reacall that it worked with qemu-0.7.2 ?

Any ideas?

-ishwar

Re: [Qemu-devel] qemu-0.8.0 and vde-1.5.9 question

[Bakul Shah]

> The system is Kanotix-2005-4
> Qemu-0.8.0
> Vde-1.5.9
> 
> I setup the bridge and add interface tun0 to the bridge
> (have done it before correctly)
> 
> but
> 
> /usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=5
> 4:52:00:12:34:62
> 
> reports error:
> qemu: invalid option -- '-tun-fd'
> qemu exited: vdeqemu quits
> 
> I seem to reacall that it worked with qemu-0.7.2 ?
> 
> Any ideas?

Just type qemu and look at its options.  They changed since
0.7.2.  Likely you want something like

	-net socket,fd=5

Also AFAIK you don't need vde anymore since qemu can do the bridging
for you (but I haven't used it so take this with a grain of salt).

In general you want to look at what changed when you update s/w.

Re: [Qemu-devel] qemu-0.8.0 and vde-1.5.9 question

[Jim C. Brown]

On Wed, Apr 05, 2006 at 03:25:18PM -0400, Ishwar Rattan wrote:
> The system is Kanotix-2005-4
> Qemu-0.8.0
> Vde-1.5.9
> 
> I setup the bridge and add interface tun0 to the bridge
> (have done it before correctly)
> 
> but
> 
> /usr/bin/vdeqemu -hda disk-image -m256 -localtime -net vde -net nic,macaddr=54:52:00:12:34:62
> 
> reports error:
> qemu: invalid option -- '-tun-fd'
> qemu exited: vdeqemu quits
> 
> I seem to reacall that it worked with qemu-0.7.2 ?
> 

qemu network options have changed.

You need vde 1.5.11 or vde2 with qemu 0.8.0 and later versions (includes cvs).

> Any ideas?
> 
> -ishwar
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.