Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32

[Jamie Lokier]

Shaddy Baddah wrote:
> >longer than MS does? It would make things easier if we
> >dropped support for W2K hosts.
> >  
> Surely not?!? I've heard of people being off hand about supporting
> Win95/98 (and I would agree with that) et al..., but surely W2K support
> should be sacrosanct ?!?

I would hope so, as I get the impression W2K is the last Windows
version which can be run reliably in a VM, due to the "legitimacy"
checking done by XP and later. :-)

-- Jamie

[Qemu-devel] [RFC] normalize error messages and use stderr in configure

[Carlo Marcelo Arenas Belon]

The following patch normalizes all (most) messages as generated by configure
so they are flagged as ERROR or WARNING (left some of the ones that look more
informative without a flag even if they result in a fatal error).

All those messages are directed to stderr so they can be filtered/identified
correctly if analyzed mechanically.  Usage information is left in stdout as it
doesn't denote abnormal behavior.

The patch is based on a modified tree (which includes several of the previous
patches sent) and won't apply cleanly and so it is not ready for merge yet.

Carlo

---
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.165
diff -u -r1.165 configure
--- configure   18 Oct 2007 20:51:48 -  1.165
+++ configure   23 Oct 2007 02:49:16 -
@@ -169,10 +168,10 @@
 if test -f /opt/SUNWspro/prod/lib/libsunmath.so.1; then
 needs_libsunmath="yes"
 else
-echo "QEMU will not link correctly on Solaris 8/X86 or 9/x86 
without"
-echo "libsunmath from the Sun Studio compilers tools, due to a 
lack of"
-echo "C99 math features in libm.so in Solaris 8/x86 and 
Solaris 9/x86"
-echo "Studio 11 can be downloaded from www.sun.com."
+echo "QEMU will not link correctly on Solaris 8/X86 or 9/x86 
without" 1>&2
+echo "libsunmath from the Sun Studio compilers tools, due to a 
lack of" 1>&2
+echo "C99 math features in libm.so in Solaris 8/x86 and 
Solaris 9/x86" 1>&2
+echo "Studio 11 can be downloaded from www.sun.com." 1>&2
 exit 1
 fi
 fi
@@ -303,9 +300,11 @@
  target_cpu="sparc"; cpu="sparc" ;;
 v9)SP_CFLAGS="-m64 -mcpu=ultrasparc -D__sparc_${sparc_cpu}__"; 
SP_LDFLAGS="-m64"
  target_cpu="sparc64"; cpu="sparc64" ;;
-*) echo "undefined SPARC architecture. Exiting";exit 1;;
+*) echo "ERROR: undefined SPARC architecture. Exiting" 1>&2; exit 
1;;
   esac
   ;;
+  *) echo "ERROR: unknown option $opt" 1>&2; show_help="yes"
+  ;;
   esac
 done
 
@@ -412,7 +412,7 @@
 if $cc -c -o $TMPO $TMPC 2> /dev/null ; then
   : C compiler works ok
 else
-echo "ERROR: \"$cc\" either does not exist or does not work"
+echo "ERROR: \"$cc\" either does not exist or does not work" 1>&2
 exit 1
 fi
 
@@ -431,26 +431,26 @@
 int main(){return 0;}
 EOF
 if "$cc" -o $TMPE $TMPC 2> /dev/null ; then
-   echo "WARNING: \"$cc\" looks like gcc 4.x"
+   echo "WARNING: \"$cc\" looks like gcc 4.x" 1>&2
found_compat_cc="no"
if test "$gcc3_search" = "yes" ; then
-   echo "Looking for gcc 3.x"
+   echo "Looking for gcc 3.x" 1>&2
for compat_cc in $gcc3_list ; do
if "$cross_prefix$compat_cc" --version 2> /dev/null | fgrep 
'(GCC) 3.' > /dev/null 2>&1 ; then
-   echo "Found \"$compat_cc\""
+   echo "Found \"$compat_cc\"" 1>&2
cc="$cross_prefix$compat_cc"
found_compat_cc="yes"
break
fi
done
if test "$found_compat_cc" = "no" ; then
-   echo "gcc 3.x not found!"
+   echo "ERROR: gcc 3.x not found!" 1>&2
fi
fi
if test "$found_compat_cc" = "no" ; then
-   echo "QEMU is known to have problems when compiled with gcc 4.x"
-   echo "It is recommended that you use gcc 3.x to build QEMU"
-   echo "To use this compiler anyway, configure with 
--disable-gcc-check"
+   echo "QEMU is known to have problems when compiled with gcc 4.x" 
1>&2
+   echo "It is recommended that you use gcc 3.x to build QEMU" 1>&2
+   echo "To use this compiler anyway, configure with 
--disable-gcc-check" 1>&2
exit 1;
fi
 fi
@@ -467,30 +467,30 @@
   if test "$solarisrev" -eq 10 -a "$check_gcc" = "yes" ; then
 solgcc=`which $cc`
 if test "$solgcc" = "/usr/sfw/bin/gcc" ; then
-  echo "Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu 
correctly."
-  echo "please get gcc-3.4.3 or later, from www.blastwave.org using 
pkg-get -i gcc3"
-  echo "or get the latest patch from SunSolve for gcc"
+  echo "Solaris 10/FCS gcc in /usr/sfw/bin will not compiled qemu 
correctly." 1>&2
+  echo "please get gcc-3.4.3 or later, from www.blastwave.org using 
pkg-get -i gcc3" 1>&2
+  echo "or get the latest patch from SunSolve for gcc" 1>&2
   exit 1
 fi
   fi
   solinst=`which $install 2> /dev/null | /usr/bin/grep -v "no $install in"`
   if test -z "$solinst" ; then
-echo "Solaris install program not found. Use --install=/usr/ucb/install or"
-echo "install fileutils from www.blastwave.org using pkg-get -i fileutils"
-echo "to get ginstall which is used by default (

[Qemu-devel] [PATCH] add gcc 3.4.6 to the list of compilers to look for

[Carlo Marcelo Arenas Belon]

The following patch adds gcc-3.4.6 (as used by gentoo's gcc-3.4.6-r2 package)
to the list of compilers to test for compatibility.

This is also the last version for the gcc-3.4.x and gcc-3.x series which
hasn't had an update in 19 months and therefore most likely stable enough to
be called by full version number.

All other distributions that don't have a binary with this name will just skip
this entry and therefore should been unaffected by the change.

Carlo

---
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.165
diff -u -r1.165 configure
--- configure   18 Oct 2007 20:51:48 -  1.165
+++ configure   23 Oct 2007 01:38:17 -
@@ -23,7 +23,7 @@
 cross_prefix=""
 cc="gcc"
 gcc3_search="yes"
-gcc3_list="gcc-3.4 gcc34 gcc-3.3.6 gcc-3.3 gcc33 gcc-3.2 gcc32"
+gcc3_list="gcc-3.4.6 gcc-3.4 gcc34 gcc-3.3.6 gcc-3.3 gcc33 gcc-3.2 gcc32"
 host_cc="gcc"
 ar="ar"
 make="make"

[Qemu-devel] [PATCH] show usage and abort if unknown option is passed to configure

[Carlo Marcelo Arenas Belon]

The following patch prints an error if an unknown option is passed to
configure and directs the script to show usage information.

Carlo

---
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.165
diff -u -r1.165 configure
--- configure   18 Oct 2007 20:51:48 -  1.165
+++ configure   23 Oct 2007 01:23:58 -
@@ -306,6 +303,8 @@
 *) echo "undefined SPARC architecture. Exiting";exit 1;;
   esac
   ;;
+  *) echo "ERROR: unknown option $opt"; show_help="yes"
+  ;;
   esac
 done
 

[Qemu-devel] [PATCH] add --disable-sdl to configure's help

[Carlo Marcelo Arenas Belon]

The following patch adds a description for --disable-sdl for configure

Carlo

---
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.165
diff -u -r1.165 configure
--- configure   18 Oct 2007 20:51:48 -  1.165
+++ configure   23 Oct 2007 01:12:17 -
@@ -377,6 +374,7 @@
 echo "  --make=MAKE  use specified make [$make]"
 echo "  --install=INSTALLuse specified install [$install]"
 echo "  --static enable static build [$static]"
+echo "  --disable-sdldisable SDL"
 echo "  --enable-cocoa   enable COCOA (Mac OS X only)"
 echo "  --enable-mingw32 enable Win32 cross compilation with mingw32"
 echo "  --enable-adlib   enable Adlib emulation"

[Qemu-devel] [RFC/PATCH] remove $check_gfx from configure

[Carlo Marcelo Arenas Belon]

The following patch removes check_gfx from qemu's configure as the check it
was trying to enforce is no longer valid.

If neither sdl or cocoa are available, the video output for the console will 
be still available from the vnc server (which can't be disabled).

Carlo

---
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.165
diff -u -r1.165 configure
--- configure   18 Oct 2007 20:51:48 -  1.165
+++ configure   23 Oct 2007 01:01:50 -
@@ -98,7 +98,6 @@
 kqemu="no"
 profiler="no"
 cocoa="no"
-check_gfx="yes"
 check_gcc="yes"
 softmmu="yes"
 linux_user="no"
@@ -276,8 +275,6 @@
   ;;
   --enable-cocoa) cocoa="yes" ; coreaudio="yes" ; sdl="no"
   ;;
-  --disable-gfx-check) check_gfx="no"
-  ;;
   --disable-gcc-check) check_gcc="no"
   ;;
   --disable-system) softmmu="no"
@@ -966,12 +963,10 @@
 ;;
 esac
 
-if test "$target_user_only" = "no" -a "$check_gfx" = "yes" \
--a "$sdl" = "no" -a "$cocoa" = "no" ; then
-echo "ERROR: QEMU requires SDL or Cocoa for graphical output"
-echo "To build QEMU without graphical output configure with 
--disable-gfx-check"
-echo "Note that this will disable all output from the virtual graphics 
card."
-exit 1;
+if test "$target_user_only" = "no" -a "$sdl" = "no" -a "$cocoa" = "no" ; then
+echo "WARNING: QEMU requires SDL or Cocoa for graphical output"
+echo "Note that in order to be able to attach to the console you'll"
+echo "need to start qemu's vncserver with --vnc and use a vnc client."
 fi
 
 #echo "Creating $config_mak, $config_h and $target_dir/Makefile"

Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32

[Shaddy Baddah]

Hi,

Stefan Weil wrote:

longer than MS does? It would make things easier if we
dropped support for W2K hosts.
  

Surely not?!? I've heard of people being off hand about supporting
Win95/98 (and I would agree with that) et al..., but surely W2K support
should be sacrosanct ?!?

Regards,
Shaddy

Re: [Qemu-devel] qemu alpha?

[J. Mayer]

On Mon, 2007-10-22 at 09:43 +0200, Oliver Falk wrote:
> On 10/21/2007 01:06 PM, J. Mayer wrote:
> > On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
> >> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
> >>> On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
>  On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> > On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> >> Hi list!
> > Hi you !
> >
> >> Just wanted to know how far the progress on alpha target is? I would
> >> be happy if I have some 'virtual alpha' to test new isos.
> >>
> >> If I can help some way (I have a few alphas around). Let me know.
> > I'm happy to see someone interresting in improving Alpha support, which
> > is  very alpha for now !
>  I'm interested in testing Alpha too, but I haven't seem a
>  qemu-system-alpha show up yet.  Alas, I have no hardware or specific
>  expertise in this platform, I'm just trying to build and boot Linux
>  kernels (and corresponding root filesystems) on as many emulated target
>  platforms as I can.
> >>> There are a lot of things missing for qemu-system-alpha to be available:
> >>> - the PALCode emulation is far from being complete or even usable
> >> I have no idea what that is.
> > 
> > The PALCode is mainly equivalent to the microcode of most CPU
> > architectures. What is different to microcode is that is uses only
> > regular Alpha instructions, just adding 4 instructions to access special
> > "hardware registers" and access the memory with different priviledge
> > levels. Another main idea is that everyone can write its own PALCode
> > image and switch to it at run-time. Then, for example, the PALCode ABI
> > is not the same one if you run Linux or Windows NT. The PALCode handles
> > all complex operations. For example, the CPU provides only TLB and the
> > MMU tables search is actually implemented in software, in the PALCode.
> > This greatly simplifies the CPU design and allows a high level of
> > flexibility. And if your OS need a specific ABI for example to handle
> > CPU exception, you define your ABI, write the PALCode using Alpha insns
> > and use it ! The Alpha CPU also provide an instruction to do PALCode
> > calls from the OS or applications.
> > There are 3 (4 ?) "native" PALCode ABIs documented in the Alpha CPUs
> > specifications then those can be emulated at the host side in Qemu. It
> > is in fact needed to emulate a subset of the PALCode even to run
> > user-mode programs.
> 
> Pretty good explained! Thanks!
> 
> 
> 
> However, what do you need to make the alpha emulation work? Does ssh to
> an Alpha help you? I'm quite sure I can offer you access to some ev5
> machine very soon and I might give access to some ds10 (ev67 machine).
> There's also some ds10 (ev6 'only') machine in Australia, that actually
> works as a builder for the AlphaCore project - but it's not mine and I
> would need to ask if I can give access to someone else...

I actually do not have a lot of time to spend of Alpha emulation, that's
why it would be great if some could test and compare the execution of
simple programs (then later more complicated one) in order to find the
most obvious emulation bugs, with the linux-user mode emulation.
For this, an access to any Alpha machine could help a lot.
For the full system emulation, a lot of work is to be done, mostly the
PALCode emulation and putting together all elements of an actual
hardware machine. Note that the PALCode emulation could be avoided if
the emulator is able to run native PALCode image but I don't know if
those images are easily available...

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Tue, 2007-10-23 at 00:05 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> >> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> >>> Hi all,
> >>>
> >>> I've been investigating more about PreP kernel boot using Qemu and I
> >>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> >>> unmodified OHW.
[...]
> >> - The "floating point" problem I reported during the week-end does
> not
> >>   exists, probably because of the switch from powerpc to ppc. I
> still 
> >>   don't know if it is a kernel problem or a QEMU problem (or both).
> > 
> > There may be issues with the floating point emulation, especially if
> > some kernel or programs relies on the FPSCR (floating-point status)
> > register which is never updated in Qemu.
> > 
> 
> Is there any technical reason behind that, or is it just a lack of
> time?

I can say  both:
for most program, using floating point arithmetic ala "fast-math", it's
not necessary to maintain a precise FPU state, as those program will
never raise any FPU exception, never generate NaNs, infinites, ...
The other reason is that it would need to check every FPU insn arguments
and results at run time and treat all special cases following the actual
PowerPC implementations behavior if we want to get a precise emulation.
This behavior could be for example selected at compile time: then one
would have the choice to have a quick FPU emulation model or a precise
one.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

J. Mayer a écrit :
> On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
>> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
>>> Hi all,
>>>
>>> I've been investigating more about PreP kernel boot using Qemu and I
>>> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
>>> unmodified OHW.
>>> The issues I found in the kernel are:
>>> - the OpenFirmware video console driver is broken in recent 2.4 kernels
>>> and have been removed from recent 2.6 kernel
>>> - I then decided to use the vga16fb console driver but needed to do some
>>> patches in order to make it compile properly
>>> - the CMOS RTC driver is not available for PPC architecture in 2.6
>>> kernels and need some patches in order to be usable
>>> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
>>> kernels. The bugs are visible only when cross-compiling from a
>>> little-endian and/or 64 bits host.
>>> - I got issues (ie process freezing) when using the 2.6.22 kernel with
>>> HZ > 100. It seems to run properly when the system timer is set to 100
>>> Hz but this needs more tests for confirmation.
>>> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
>>> when it has no RTC available. There is no problem when the RTC is
>>> present. This is likely to be a kernel bug: when no RTC is available, it
>>> cannot calibrate its timers properly and the kernel timer seems to run
>>> very fast. Forcing (with hacks...) the timer to run at nearly real-time
>>> seems to prevent the bug to happen.
>>>
>>> I then generated some kernels that allow me to boot and use those 3
>>> kernels.
>>> Here are 3 tarballs with:
>>> - a patch to be applied to the vanilla kernel sources to fix the
>>> mentionned bugs
>>> - the .config file I used to build the kernel
>>> - the zImage.prep image
>>> 
>>> 
>>> 
>>>
>>> I then run Qemu with the following command line template:
>>> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
>>> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
>>> -cpu 604 -M prep -L pc-bios/ -hda  -cdrom 
>>> -kernel
>>> /linux-.patched/arch/ppc/boot/images/zImage.prep
>>>
>>> Hope this helps.
>>>
>> Yes, this help a lot, thanks! With your config file, I have been able to
>> build and boot a 2.6.22 kernel. I have used a Debian sid chroot.
>>
>> Here are a few remarks:
>> - The NE2000 card doesn't work for the same reason as with the powerpc
>>   architecture. The kernel patch below fixes the problem. I will send it
>>   later along with the ppc patch.
> 
> There's something else strange with the PCI ethernet devices: they got
> no IRQ assigned (as if the BIOS does not configure them properly). And
> the RTL8139 never has a mac address, never detects the PHY link, then
> there may be endianness issues in the emulation (I did not check at
> all).
> 
>> - The "floating point" problem I reported during the week-end does not
>>   exists, probably because of the switch from powerpc to ppc. I still 
>>   don't know if it is a kernel problem or a QEMU problem (or both).
> 
> There may be issues with the floating point emulation, especially if
> some kernel or programs relies on the FPSCR (floating-point status)
> register which is never updated in Qemu.
> 

Is there any technical reason behind that, or is it just a lack of time?


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

Re: [Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > Hi all,
> > 
> > I've been investigating more about PreP kernel boot using Qemu and I
> > achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > unmodified OHW.
> > The issues I found in the kernel are:
> > - the OpenFirmware video console driver is broken in recent 2.4 kernels
> > and have been removed from recent 2.6 kernel
> > - I then decided to use the vga16fb console driver but needed to do some
> > patches in order to make it compile properly
> > - the CMOS RTC driver is not available for PPC architecture in 2.6
> > kernels and need some patches in order to be usable
> > - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> > kernels. The bugs are visible only when cross-compiling from a
> > little-endian and/or 64 bits host.
> > - I got issues (ie process freezing) when using the 2.6.22 kernel with
> > HZ > 100. It seems to run properly when the system timer is set to 100
> > Hz but this needs more tests for confirmation.
> > - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> > when it has no RTC available. There is no problem when the RTC is
> > present. This is likely to be a kernel bug: when no RTC is available, it
> > cannot calibrate its timers properly and the kernel timer seems to run
> > very fast. Forcing (with hacks...) the timer to run at nearly real-time
> > seems to prevent the bug to happen.
> > 
> > I then generated some kernels that allow me to boot and use those 3
> > kernels.
> > Here are 3 tarballs with:
> > - a patch to be applied to the vanilla kernel sources to fix the
> > mentionned bugs
> > - the .config file I used to build the kernel
> > - the zImage.prep image
> > 
> > 
> > 
> > 
> > I then run Qemu with the following command line template:
> > ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> > tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> > -cpu 604 -M prep -L pc-bios/ -hda  -cdrom 
> > -kernel
> > /linux-.patched/arch/ppc/boot/images/zImage.prep
> > 
> > Hope this helps.
> > 
> 
> Yes, this help a lot, thanks! With your config file, I have been able to
> build and boot a 2.6.22 kernel. I have used a Debian sid chroot.
> 
> Here are a few remarks:
> - The NE2000 card doesn't work for the same reason as with the powerpc
>   architecture. The kernel patch below fixes the problem. I will send it
>   later along with the ppc patch.

There's something else strange with the PCI ethernet devices: they got
no IRQ assigned (as if the BIOS does not configure them properly). And
the RTL8139 never has a mac address, never detects the PHY link, then
there may be endianness issues in the emulation (I did not check at
all).

> - The "floating point" problem I reported during the week-end does not
>   exists, probably because of the switch from powerpc to ppc. I still 
>   don't know if it is a kernel problem or a QEMU problem (or both).

There may be issues with the floating point emulation, especially if
some kernel or programs relies on the FPSCR (floating-point status)
register which is never updated in Qemu.

> - PCI is broken. PCI IDs are reported in the wrong endianness:
>   00:00.0 Non-VGA unclassified device: Unknown device 0148:5710 (rev 06)
>   00:01.0 Non-VGA unclassified device: Santa Cruz Operation Unknown device 
> 3412 (rev 03)

This does not happen with 2.4 kernels. Using the 2.4.35 image, all PCI
descriptors are OK and the drivers properly recognize the devices. What
I suspect is that 2.6 kernels tweak the chipset to make it handle the
endian-reverse accesses.

[...]

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized

Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32

[Johannes Schindelin]

Hi,

On Mon, 22 Oct 2007, Stefan Weil wrote:

> Ivan Kalvachev schrieb:
> > According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx
> >
> > this function requires Win XP or Vista.
> > Is qemu supported only on these?
>
> Good question. The old IOCTL_DISK_GET_DRIVE_GEOMETRY was also supported 
> for W2K. Will QEMU support W2K as a host longer than MS does? It would 
> make things easier if we dropped support for W2K hosts.

Do we really want to be as evil as Microsoft and force all users to 
upgrade?

It should not be _that_ hard to stay at least a _little_ backwards 
compatible.

Ciao,
Dscho

Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32

[Stefan Weil]

Ivan Kalvachev schrieb:
> According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx
>
> this function requires Win XP or Vista.
> Is qemu supported only on these?
Good question. The old IOCTL_DISK_GET_DRIVE_GEOMETRY
was also supported for W2K. Will QEMU support W2K as a host
longer than MS does? It would make things easier if we
dropped support for W2K hosts.

If we need host support for W2K, I'll check another method
to get the disk size (reading size of partition 0) and send
a new patch. Please send your feedback in this case.

I hope we don't need W95 or W98 host support!?

Stefan

[Qemu-devel] Strange behaviour

[Christian Fontana]

Hello.

I'm using QEMU to expirement configuration, sw,... so I've create some images 
with different linux distros.

Yesterday I've upgraded my Kubuntu from 7.04 to 7.10 and so also qemu was 
upgraded from 0.8.2 to 0.9.0. What I discovered is that some VM I've created 
(in particular suse) now are not working: they aren0t able to mount disk.

What can I do? I tried the same disks on a not-upgraded kubuntu and everything 
works fine. 

Ciao 
Christian

Re: [Qemu-devel] PreP kernels boot using Qemu

[Aurelien Jarno]

On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> Hi all,
> 
> I've been investigating more about PreP kernel boot using Qemu and I
> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> unmodified OHW.
> The issues I found in the kernel are:
> - the OpenFirmware video console driver is broken in recent 2.4 kernels
> and have been removed from recent 2.6 kernel
> - I then decided to use the vga16fb console driver but needed to do some
> patches in order to make it compile properly
> - the CMOS RTC driver is not available for PPC architecture in 2.6
> kernels and need some patches in order to be usable
> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> kernels. The bugs are visible only when cross-compiling from a
> little-endian and/or 64 bits host.
> - I got issues (ie process freezing) when using the 2.6.22 kernel with
> HZ > 100. It seems to run properly when the system timer is set to 100
> Hz but this needs more tests for confirmation.
> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> when it has no RTC available. There is no problem when the RTC is
> present. This is likely to be a kernel bug: when no RTC is available, it
> cannot calibrate its timers properly and the kernel timer seems to run
> very fast. Forcing (with hacks...) the timer to run at nearly real-time
> seems to prevent the bug to happen.
> 
> I then generated some kernels that allow me to boot and use those 3
> kernels.
> Here are 3 tarballs with:
> - a patch to be applied to the vanilla kernel sources to fix the
> mentionned bugs
> - the .config file I used to build the kernel
> - the zImage.prep image
> 
> 
> 
> 
> I then run Qemu with the following command line template:
> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> -cpu 604 -M prep -L pc-bios/ -hda  -cdrom 
> -kernel
> /linux-.patched/arch/ppc/boot/images/zImage.prep
> 
> Hope this helps.
> 

Yes, this help a lot, thanks! With your config file, I have been able to
build and boot a 2.6.22 kernel. I have used a Debian sid chroot.

Here are a few remarks:
- The NE2000 card doesn't work for the same reason as with the powerpc
  architecture. The kernel patch below fixes the problem. I will send it
  later along with the ppc patch.
- The "floating point" problem I reported during the week-end does not
  exists, probably because of the switch from powerpc to ppc. I still 
  don't know if it is a kernel problem or a QEMU problem (or both).
- PCI is broken. PCI IDs are reported in the wrong endianness:
  00:00.0 Non-VGA unclassified device: Unknown device 0148:5710 (rev 06)
  00:01.0 Non-VGA unclassified device: Santa Cruz Operation Unknown device 3412 
(rev 03)

Otherwise everything works fine for me, it looks a bit faster than 
MIPS(el) emulation (which is faster than ARM and SPARC). I still haven't 
done that much tests though.  


Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>

diff --git a/arch/ppc/syslib/i8259.c b/arch/ppc/syslib/i8259.c
index 1e5a00a..559f27c 100644
--- a/arch/ppc/syslib/i8259.c
+++ b/arch/ppc/syslib/i8259.c
@@ -127,6 +127,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
 static struct irq_chip i8259_pic = {
.typename   = " i8259",
.mask   = i8259_mask_irq,
+   .disable= i8259_mask_irq,
.unmask = i8259_unmask_irq,
.mask_ack   = i8259_mask_and_ack_irq,
 };


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

RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Arnon Gilboa]

Thanks, Paul.
The attached updated patch seems to fix this bug.
Comments? 

-Original Message-
From: Paul Brook [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 22, 2007 1:53 PM
To: qemu-devel@nongnu.org
Cc: Arnon Gilboa
Subject: Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support

On Monday 22 October 2007, Arnon Gilboa wrote:
> Hi,
>
> The attached patch adds isochronous transfers support to the OHCI 
> emulation, similarly to the UHCI patch pushed two weeks ago.

> +uint16_t offset[8];
> +};

> +static inline int ohci_read_iso_td(uint32_t addr, struct ohci_iso_td 
> +*td) {
> +return get_dwords(addr, (uint32_t *)td, sizeof(*td) >> 2); }

This is wrong. It will break on big-endian hosts.
set_dwords only DTRT if all the structure fields are 32-bit.

Paul


usb-ohci-iso.patch
Description: usb-ohci-iso.patch

[Qemu-devel] Redirect your Webcam

[Arnon Gilboa]

Please connect your Webcam (or any other USB isochronous device) and
redirect it, using the UHCI (already in qemu head) and OHCI isochronous
patches.

I need your feedback.

TIA,
Arnon

Re: [Qemu-devel] What happened with NPTL/TLS support?

[Thayne Harbaugh]

On Sat, 2007-10-20 at 21:34 +0100, Thiemo Seufer wrote:
> Thayne Harbaugh wrote:
> > 
> > On Fri, 2007-10-12 at 18:12 +0300, Felipe Contreras wrote:
> > > Hi,
> > > 
> > > When I try to use codesourcery's toolchain arm-2006q3-27 in my Fedora
> > > 7 box I always have the following issue:
> > > 
> > > qemu: Unsupported syscall: 983045
> > 
> > Yep, I've seen that before.
> > 
> > > I guess it's a problem of NPTL incompatibility. Anyway, the patch that
> > > Paul Brook sent a while ago solves it [1].
> > > 
> > > I wonder if it can be integrated or what would be the right way to
> > > solve this issue. Am I the only one having it?
> > > 
> > > Best regards.
> > > 
> > > [1] http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00128.html
> > 
> > 
> > I've been using this patch, as well as other NPTL/TLS patches as well as
> > some of my own work and have a set of patches for NPTL/TLS that works
> > reasonably well for arm and i386.  The patches don't apply cleanly to
> > CVS current, but I'm more than happy to rework them so that they will if
> > someone is serious about getting NPTL/TLS/futex stuff working for
> > linux-user.  I haven't submitted my patches because I kept expecting the
> > other patches to be accepted.
> 
> Please submit this patch (and resend what you think was missed).

I'll get them reworked and re-sent soon.

Thanks for the interest.

Re: [Qemu-devel] qemu-i386 does not start on x86_64 or i686

[Thayne Harbaugh]

On Thu, 2007-10-18 at 23:46 +0200, Ronan Keryell wrote:
> Anybody kind enough to have a look at :
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446868
> 
> I've asked some other people and they hit the same issue.
> It's not clear to me where the bug is since it happens very early in the
> starting process...


I've been using this patch:

Index: qemu/linux-user/main.c
===
--- qemu.orig/linux-user/main.c 2007-10-15 13:52:13.0 -0600
+++ qemu/linux-user/main.c  2007-10-15 13:52:13.0 -0600
@@ -44,7 +44,7 @@
 
 /* for recent libc, we add these dummy symbols which are not declared
when generating a linked object (bug in ld ?) */
-#if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) && 
!defined(CONFIG_STATIC)
+#if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 3) && !defined(CONFIG_STATIC)
 long __preinit_array_start[0];
 long __preinit_array_end[0];
 long __init_array_start[0];

RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Arnon Gilboa]

no. uhci & ohci are for usb 1.1. ehci is for usb 2.0 and i have just
started working on its qemu emulation.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Itamar Heim
Sent: Monday, October 22, 2007 12:30 PM
To: qemu-devel@nongnu.org
Subject: RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support

So this is isochronous for usb 2.0?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Arnon Gilboa
Sent: Monday, October 22, 2007 12:19 PM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support

Hi,

The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.

In order to use ohci instead of uhci, replace the following line in
pc.c:
usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);

With:
usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2);

Any comments?

Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Hetz Ben Hamo]

Hi Itamar,

On 22/10/2007, Itamar Heim <[EMAIL PROTECTED]> wrote:
>
> So this is isochronous for usb 2.0?
>

last I checked, OHCI is for USB 1.x, EHCI was for 2.0.

Thanks,
Hetz
-- 
Skepticism is the lazy person's default position.
my blog (hebrew): http://benhamo.org

RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Itamar Heim]

So this is isochronous for usb 2.0?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Arnon Gilboa
Sent: Monday, October 22, 2007 12:19 PM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support

Hi,

The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.

In order to use ohci instead of uhci, replace the following line in
pc.c:
usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);

With:
usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2);

Any comments?

Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Paul Brook]

On Monday 22 October 2007, Arnon Gilboa wrote:
> Hi,
>
> The attached patch adds isochronous transfers support to the OHCI
> emulation, similarly to the UHCI patch pushed two weeks ago.

> +uint16_t offset[8];
> +};

> +static inline int ohci_read_iso_td(uint32_t addr, struct ohci_iso_td *td)
> +{
> +return get_dwords(addr, (uint32_t *)td, sizeof(*td) >> 2);
> +}

This is wrong. It will break on big-endian hosts.
set_dwords only DTRT if all the structure fields are 32-bit.

Paul

Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32

[Ivan Kalvachev]

2007/10/19, Stefan Weil <[EMAIL PROTECTED]>:
> Hi,
>
> raw harddisk access for Windows (//./PhysicalDrive0) gives wrong disk sizes.
> You can check this by booting a harddisk with the GRUB bootloader installed
> and using GRUB's geometry command.
>
> The current QEMU code uses IOCTL_DISK_GET_DRIVE_GEOMETRY which is marked
> as obsolete by MS.
>
> The appended patch gives correct results. Please apply it to CVS.
>
> Stefan
>
> Description of block-raw.patch:
>
> * replace IOCTL_DISK_GET_DRIVE_GEOMETRY by IOCTL_DISK_GET_DRIVE_GEOMETRY_EX


According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx
this function requires Win XP or Vista.
Is qemu supported only on these?

Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Michal Schulz]

On Monday 22 October 2007, Arnon Gilboa wrote:

> Good idea

Let me quote my ancient email (sent on this list on 29.03.2007 23:34):

> Hello. I've made small patch for qemu, which adds a new command line
> option - > the "-ohci". It instructs qemu that the OHCI controller should be
> emulated instead of the default UHCI. What do you think about it?

-- 
Michal Schulz
diff -Naur qemu-0.9.0/hw/pc.c qemu-0.9.0-ohci-patch/hw/pc.c
--- qemu-0.9.0/hw/pc.c	2007-02-06 00:01:54.0 +0100
+++ qemu-0.9.0-ohci-patch/hw/pc.c	2007-03-29 15:43:18.0 +0200
@@ -695,7 +695,10 @@
 cmos_init(ram_size, boot_device, bs_table);
 
 if (pci_enabled && usb_enabled) {
-usb_uhci_init(pci_bus, piix3_devfn + 2);
+if (use_ohci_instead)
+	usb_ohci_init(pci_bus, 3, -1);
+	else
+usb_uhci_init(pci_bus, piix3_devfn + 2);
 }
 
 if (pci_enabled && acpi_enabled) {
diff -Naur qemu-0.9.0/vl.c qemu-0.9.0-ohci-patch/vl.c
--- qemu-0.9.0/vl.c	2007-02-06 00:01:54.0 +0100
+++ qemu-0.9.0-ohci-patch/vl.c	2007-03-29 15:44:52.0 +0200
@@ -155,6 +155,7 @@
 int win2k_install_hack = 0;
 #endif
 int usb_enabled = 0;
+int use_ohci_instead = 0;
 static VLANState *first_vlan;
 int smp_cpus = 1;
 const char *vnc_display;
@@ -6048,6 +6049,7 @@
"-win2k-hack use it when installing Windows 2000 to avoid a disk full bug\n"
 #endif
"-usbenable the USB driver (will be the default soon)\n"
+	   "-ohci   use the OHCI controller instead of the UHCI\n"
"-usbdevice name add the host or guest USB device 'name'\n"
 #if defined(TARGET_PPC) || defined(TARGET_SPARC)
"-g WxH[xDEPTH]  Set the initial graphical resolution and depth\n"
@@ -6198,6 +6200,7 @@
 QEMU_OPTION_kernel_kqemu,
 QEMU_OPTION_win2k_hack,
 QEMU_OPTION_usb,
+QEMU_OPTION_ohci,
 QEMU_OPTION_usbdevice,
 QEMU_OPTION_smp,
 QEMU_OPTION_vnc,
@@ -6284,6 +6287,7 @@
 
 /* temporary options */
 { "usb", 0, QEMU_OPTION_usb },
+{ "ohci", 0, QEMU_OPTION_ohci },
 { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
 { "no-acpi", 0, QEMU_OPTION_no_acpi },
 { "no-reboot", 0, QEMU_OPTION_no_reboot },
@@ -6917,6 +6921,9 @@
 case QEMU_OPTION_usb:
 usb_enabled = 1;
 break;
+	case QEMU_OPTION_ohci:
+	use_ohci_instead = 1;
+		break;
 case QEMU_OPTION_usbdevice:
 usb_enabled = 1;
 if (usb_devices_index >= MAX_USB_CMDLINE) {
diff -Naur qemu-0.9.0/vl.h qemu-0.9.0-ohci-patch/vl.h
--- qemu-0.9.0/vl.h	2007-02-06 00:01:54.0 +0100
+++ qemu-0.9.0-ohci-patch/vl.h	2007-03-29 15:42:19.0 +0200
@@ -155,6 +155,7 @@
 extern int kqemu_allowed;
 extern int win2k_install_hack;
 extern int usb_enabled;
+extern int use_ohci_instead;
 extern int smp_cpus;
 extern int no_quit;
 extern int semihosting_enabled;

RE: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Arnon Gilboa]

Good idea 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Dor Laor
Sent: Monday, October 22, 2007 12:45 PM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers
support

Arnon Gilboa wrote:
>
> Hi,
>
> The attached patch adds isochronous transfers support to the OHCI 
> emulation, similarly to the UHCI patch pushed two weeks ago.
>
> In order to use ohci instead of uhci, replace the following line in
> pc.c:
> usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);
>
> With:
> usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2);
>
> Any comments?
>
What about making it dynamically set by cmdline?
Dor

Re: [Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Dor Laor]

Arnon Gilboa wrote:


Hi,

The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.

In order to use ohci instead of uhci, replace the following line in
pc.c:
usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);

With:
usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2);

Any comments?


What about making it dynamically set by cmdline?
Dor

[Qemu-devel] [PATCH, RFC] USB OHCI isochronous transfers support

[Arnon Gilboa]

Hi,

The attached patch adds isochronous transfers support to the OHCI
emulation, similarly to the UHCI patch pushed two weeks ago.

In order to use ohci instead of uhci, replace the following line in
pc.c:
usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);

With:
usb_ohci_init_pci(pci_bus, 3, piix3_devfn + 2);

Any comments?


usb-ohci-iso.patch
Description: usb-ohci-iso.patch

Re: [Qemu-devel] PreP kernels boot using Qemu

[Jocelyn Mayer]

On Mon, 2007-10-22 at 09:36 +0200, J. Mayer wrote:
> Hi all,
> 
> I've been investigating more about PreP kernel boot using Qemu and I
> achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> unmodified OHW.
> The issues I found in the kernel are:
> - the OpenFirmware video console driver is broken in recent 2.4 kernels
> and have been removed from recent 2.6 kernel
> - I then decided to use the vga16fb console driver but needed to do some
> patches in order to make it compile properly
> - the CMOS RTC driver is not available for PPC architecture in 2.6
> kernels and need some patches in order to be usable
> - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> kernels. The bugs are visible only when cross-compiling from a
> little-endian and/or 64 bits host.
> - I got issues (ie process freezing) when using the 2.6.22 kernel with
> HZ > 100. It seems to run properly when the system timer is set to 100
> Hz but this needs more tests for confirmation.
> - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> when it has no RTC available. There is no problem when the RTC is
> present. This is likely to be a kernel bug: when no RTC is available, it
> cannot calibrate its timers properly and the kernel timer seems to run
> very fast. Forcing (with hacks...) the timer to run at nearly real-time
> seems to prevent the bug to happen.
> 
> I then generated some kernels that allow me to boot and use those 3
> kernels.
> Here are 3 tarballs with:
> - a patch to be applied to the vanilla kernel sources to fix the
> mentionned bugs
> - the .config file I used to build the kernel
> - the zImage.prep image
> 
> 
> 
> 
> I then run Qemu with the following command line template:
> ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> -cpu 604 -M prep -L pc-bios/ -hda  -cdrom 
> -kernel
> /linux-.patched/arch/ppc/boot/images/zImage.prep
> 
> Hope this helps.

Two points I forgot:
- there is no way to make Qemu stop when the PreP kernel displays "Power
down" because the prep_halt routine just does an infinite loop.
- the board reset would not work with the current code. I will fix this
soon.


-- 
Jocelyn Mayer <[EMAIL PROTECTED]>

RE: [Qemu-devel] qemu/hw piix_pci.c

[Igor Lvovsky]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Michael Hanselmann
> Sent: Monday, October 22, 2007 10:27 AM
> To: qemu-devel@nongnu.org
> Cc: Avi Kivity
> Subject: Re: [Qemu-devel] qemu/hw piix_pci.c
> 
> On Mon, Oct 22, 2007 at 12:52:30AM -0700, Igor Lvovsky wrote:
> > My last patch can be temporary workaround and now we can get the ACPI
> > interrupts without disrupt anything  else, but I'll try to find full
> > solution for this issue.
> 
> Interestingly, Linux doesn't receive any interrupts from ACPI, too.
> There must be something wrong with the hardware emulation.

[Igor Lvovsky] Probably, I will go over the spec again.

> 
> At [1] you can find a question I sent to this list, but didn't get a
> response. Just yesterday I started working on it again and it still
> doesn't work, even with your patch. 

[Igor Lvovsky] My patch fixes it for windows guest. I tried it for LID 
open/close events on my laptop. According to the spec OS should care these 
events through ACPI.
Now I have it works on windows guests via ACPI events, but on Linux guest it 
work without ACPI (weird).


Before I start going through all the
> ACPI specs and the Linux driver's code, do you have an idea what might
> be the problem?

[Igor Lvovsky] Not yet, but I'll inform you if I'll find something

> 
> Thanks,
> Michael
> 
> [1] http://lists.gnu.org/archive/html/qemu-devel/2007-06/msg00450.html
> 
> --
> http://hansmi.ch/
> 

Re: [Qemu-devel] RFC: avoid #ifdef for target cpu list - for x86, too.

[Dan Kenigsberg]

On Mon, Oct 22, 2007 at 01:47:42AM +0100, Thiemo Seufer wrote:
> Dan Kenigsberg wrote:
> > This seems like a good excuse to send my suggested -cpu option for the
> > x86 target. It is just like my previous "take 4", but fits to the newly
> > unified cpu_list.
> 
> Leads to an instant segfault for the i386 usermode emulation.
> 

Ouch. You are NOT my alpha tester, but I suspect that 

--- a/target-i386/helper2.c
+++ b/target-i386/helper2.c
@@ -97,7 +97,7 @@ static void add_flagname_to_bitmaps(char *flagname, uint32_t 
*features, uint32_t
 return;
 }
 for ( i = 0 ; i < 32 ; i++ ) 
-if (ext3_feature[i] && !strcmp (flagname, ext3_feature_name[i])) {
+if (ext3_feature_name[i] && !strcmp (flagname, ext3_feature_name[i])) {
 *ext3_features |= 1 << i;
 return;
 }

is my embarrassing typo. I resubmit the whole thing below:

diff --git a/hw/pc.c b/hw/pc.c
index c561cbf..a0c824f 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -667,7 +667,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int 
boot_device,
  DisplayState *ds, const char **fd_filename, int snapshot,
  const char *kernel_filename, const char *kernel_cmdline,
  const char *initrd_filename,
- int pci_enabled)
+ int pci_enabled, const char *cpu_model)
 {
 char buf[1024];
 int ret, linux_boot, i;
@@ -683,6 +683,13 @@ static void pc_init1(int ram_size, int vga_ram_size, int 
boot_device,
 linux_boot = (kernel_filename != NULL);
 
 /* init CPUs */
+if (cpu_model == NULL)
+cpu_model = "basic";
+
+if (x86_find_cpu_by_name(cpu_model)) {
+fprintf(stderr, "Unable to find x86 CPU definition\n");
+exit(1);
+}
 for(i = 0; i < smp_cpus; i++) {
 env = cpu_init();
 if (i != 0)
@@ -951,7 +958,7 @@ static void pc_init_pci(int ram_size, int vga_ram_size, int 
boot_device,
 pc_init1(ram_size, vga_ram_size, boot_device,
  ds, fd_filename, snapshot,
  kernel_filename, kernel_cmdline,
- initrd_filename, 1);
+ initrd_filename, 1, cpu_model);
 }
 
 static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
@@ -965,7 +972,7 @@ static void pc_init_isa(int ram_size, int vga_ram_size, int 
boot_device,
 pc_init1(ram_size, vga_ram_size, boot_device,
  ds, fd_filename, snapshot,
  kernel_filename, kernel_cmdline,
- initrd_filename, 0);
+ initrd_filename, 0, cpu_model);
 }
 
 QEMUMachine pc_machine = {
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 2341990..e92fc31 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -274,23 +274,56 @@
 #define CPUID_CMOV (1 << 15)
 #define CPUID_PAT  (1 << 16)
 #define CPUID_PSE36   (1 << 17)
+#define CPUID_PN   (1 << 18)
 #define CPUID_CLFLUSH (1 << 19)
-/* ... */
+#define CPUID_DTS (1 << 21)
+#define CPUID_ACPI (1 << 22)
 #define CPUID_MMX  (1 << 23)
 #define CPUID_FXSR (1 << 24)
 #define CPUID_SSE  (1 << 25)
 #define CPUID_SSE2 (1 << 26)
+#define CPUID_SS (1 << 27)
+#define CPUID_HT (1 << 28)
+#define CPUID_TM (1 << 29)
+#define CPUID_IA64 (1 << 30)
+#define CPUID_PBE (1 << 31)
 
 #define CPUID_EXT_SSE3 (1 << 0)
 #define CPUID_EXT_MONITOR  (1 << 3)
+#define CPUID_EXT_DSCPL(1 << 4)
+#define CPUID_EXT_VMX  (1 << 5)
+#define CPUID_EXT_SMX  (1 << 6)
+#define CPUID_EXT_EST  (1 << 7)
+#define CPUID_EXT_TM2  (1 << 8)
+#define CPUID_EXT_SSSE3(1 << 9)
+#define CPUID_EXT_CID  (1 << 10)
 #define CPUID_EXT_CX16 (1 << 13)
+#define CPUID_EXT_XTPR (1 << 14)
+#define CPUID_EXT_DCA  (1 << 17)
+#define CPUID_EXT_POPCNT   (1 << 22)
 
 #define CPUID_EXT2_SYSCALL (1 << 11)
+#define CPUID_EXT2_MP  (1 << 19)
 #define CPUID_EXT2_NX  (1 << 20)
+#define CPUID_EXT2_MMXEXT  (1 << 22)
 #define CPUID_EXT2_FFXSR   (1 << 25)
+#define CPUID_EXT2_PDPE1GB (1 << 26)
+#define CPUID_EXT2_RDTSCP  (1 << 27)
 #define CPUID_EXT2_LM  (1 << 29)
+#define CPUID_EXT2_3DNOWEXT (1 << 30)
+#define CPUID_EXT2_3DNOW   (1 << 31)
 
+#define CPUID_EXT3_LAHF_LM (1 << 0)
+#define CPUID_EXT3_CMP_LEG (1 << 1)
 #define CPUID_EXT3_SVM (1 << 2)
+#define CPUID_EXT3_EXTAPIC (1 << 3)
+#define CPUID_EXT3_CR8LEG  (1 << 4)
+#define CPUID_EXT3_ABM (1 << 5)
+#define CPUID_EXT3_SSE4A   (1 << 6)
+#define CPUID_EXT3_MISALIGNSSE (1 << 7)
+#define CPUID_EXT3_3DNOWPREFETCH (1 << 8)
+#define CPUID_EXT3_OSVW(1 << 9)
+#define CPUID_EXT3_IBS (1 << 10)
 
 #define EXCP00_DIVZ0
 #define EXCP01_SSTP1
@@ -566,6 +599,9 @@ typedef struct CPUX86State {
 CPUX86State *cpu_x86_init(void);
 int cpu_x86_exec(CPUX86State *s);
 void cpu_x86_close(CPUX86State *s);
+int x86_find_cpu_by_name (const unsigned char *name);
+void x86_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
+ ...));
 int cpu_get_pic_interrupt(CPUX86State *s);
 /*

Re: [Qemu-devel] qemu/hw piix_pci.c

[Michael Hanselmann]

On Mon, Oct 22, 2007 at 12:52:30AM -0700, Igor Lvovsky wrote:
> My last patch can be temporary workaround and now we can get the ACPI 
> interrupts without disrupt anything  else, but I'll try to find full
> solution for this issue.

Interestingly, Linux doesn't receive any interrupts from ACPI, too.
There must be something wrong with the hardware emulation.

At [1] you can find a question I sent to this list, but didn't get a
response. Just yesterday I started working on it again and it still
doesn't work, even with your patch. Before I start going through all the
ACPI specs and the Linux driver's code, do you have an idea what might
be the problem?

Thanks,
Michael

[1] http://lists.gnu.org/archive/html/qemu-devel/2007-06/msg00450.html

-- 
http://hansmi.ch/

RE: [Qemu-devel] qemu/hw piix_pci.c

[Igor Lvovsky]

> -Original Message-
> From: Thiemo Seufer [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 22, 2007 12:16 AM
> To: Avi Kivity
> Cc: qemu-devel@nongnu.org; Igor Lvovsky
> Subject: Re: [Qemu-devel] qemu/hw piix_pci.c
> 
> Avi Kivity wrote:
> >> Modified files:
> >>hw : piix_pci.c
> >> Log message:
> >>Enable ACPI interrupts, by Igor Lvovsky.
> >>
> >> CVSWeb URLs:
> >>
> http://cvs.savannah.gnu.org/viewcvs/qemu/hw/piix_pci.c?cvsroot=qemu&r1=1.1
> 1&r2=1.12
> >>
> >>
> >
> > IMO this is a bug.  The patch enables the ACPI PCI interrupt every time
> it
> > is asserted.  If this is really needed, this implies that the guest OS
> > detects some sort of inconsistency and keeps turning the ACPI interrupt
> > off.
> >
> > The bug should be addressed instead of worked-around in this way.
> 
> Igor, could you clarify what happens there?

[Igor Lvovsky] Yes sure. I rechecked it and it seems like reasonable conclusion.
As I mentioned before, enable bit of PIRQRCA should be 0, but somehow
Windows set it all the time. One of the reasons can be some sort 
of inconsistency.
My last patch can be temporary workaround and now we can get the ACPI 
interrupts without disrupt anything  else, but I'll try to find full solution 
for this issue.
Igor
 



> 
> 
> Thiemo

Re: [Qemu-devel] qemu alpha?

[Oliver Falk]

On 10/21/2007 01:06 PM, J. Mayer wrote:
> On Sun, 2007-10-21 at 05:43 -0500, Rob Landley wrote:
>> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
>>> On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
 On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
> On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
>> Hi list!
> Hi you !
>
>> Just wanted to know how far the progress on alpha target is? I would
>> be happy if I have some 'virtual alpha' to test new isos.
>>
>> If I can help some way (I have a few alphas around). Let me know.
> I'm happy to see someone interresting in improving Alpha support, which
> is  very alpha for now !
 I'm interested in testing Alpha too, but I haven't seem a
 qemu-system-alpha show up yet.  Alas, I have no hardware or specific
 expertise in this platform, I'm just trying to build and boot Linux
 kernels (and corresponding root filesystems) on as many emulated target
 platforms as I can.
>>> There are a lot of things missing for qemu-system-alpha to be available:
>>> - the PALCode emulation is far from being complete or even usable
>> I have no idea what that is.
> 
> The PALCode is mainly equivalent to the microcode of most CPU
> architectures. What is different to microcode is that is uses only
> regular Alpha instructions, just adding 4 instructions to access special
> "hardware registers" and access the memory with different priviledge
> levels. Another main idea is that everyone can write its own PALCode
> image and switch to it at run-time. Then, for example, the PALCode ABI
> is not the same one if you run Linux or Windows NT. The PALCode handles
> all complex operations. For example, the CPU provides only TLB and the
> MMU tables search is actually implemented in software, in the PALCode.
> This greatly simplifies the CPU design and allows a high level of
> flexibility. And if your OS need a specific ABI for example to handle
> CPU exception, you define your ABI, write the PALCode using Alpha insns
> and use it ! The Alpha CPU also provide an instruction to do PALCode
> calls from the OS or applications.
> There are 3 (4 ?) "native" PALCode ABIs documented in the Alpha CPUs
> specifications then those can be emulated at the host side in Qemu. It
> is in fact needed to emulate a subset of the PALCode even to run
> user-mode programs.

Pretty good explained! Thanks!



However, what do you need to make the alpha emulation work? Does ssh to
an Alpha help you? I'm quite sure I can offer you access to some ev5
machine very soon and I might give access to some ds10 (ev67 machine).
There's also some ds10 (ev6 'only') machine in Australia, that actually
works as a builder for the AlphaCore project - but it's not mine and I
would need to ask if I can give access to someone else...

-of

Re: [Qemu-devel] qemu alpha?

[Oliver Falk]

On 10/21/2007 12:55 PM, Paul Brook wrote:
>>> - there is no hardware machine emulation for Alpha in Qemu.
>>> As I have no Alpha platform, I don't know much about the hardware to be
>>> emulated.
>> I do know that the ev6 bus is the same as the Athlon used.
> 
> The CPU bus is pretty much irelevant. It's almost entirely transparent from a 
> software/emulation PoV.
> 
> IIUC some of the alpha machines did use fairly standard PC-style peripherals 
> though.

Yes. That's actually right. There where PCs that actually looked like a
standard PC - inside and outside. But it had a Alpha CPU and AlphaBios
of course :-)

-of

Re: [Qemu-devel] qemu alpha?

[Oliver Falk]

On 10/21/2007 12:43 PM, Rob Landley wrote:
> On Saturday 20 October 2007 3:56:12 am J. Mayer wrote:
>> On Fri, 2007-10-19 at 19:49 -0500, Rob Landley wrote:
>>> On Sunday 14 October 2007 5:14:27 am J. Mayer wrote:
 On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> Just wanted to know how far the progress on alpha target is? I would
> be happy if I have some 'virtual alpha' to test new isos.
>
> If I can help some way (I have a few alphas around). Let me know.
 I'm happy to see someone interresting in improving Alpha support, which
 is  very alpha for now !
>>> I'm interested in testing Alpha too, but I haven't seem a
>>> qemu-system-alpha show up yet.  Alas, I have no hardware or specific
>>> expertise in this platform, I'm just trying to build and boot Linux
>>> kernels (and corresponding root filesystems) on as many emulated target
>>> platforms as I can.
>> There are a lot of things missing for qemu-system-alpha to be available:
>> - the PALCode emulation is far from being complete or even usable
> 
> I have no idea what that is.
> 
>> - there is no hardware machine emulation for Alpha in Qemu.
>> As I have no Alpha platform, I don't know much about the hardware to be
>> emulated.
> 
> I do know that the ev6 bus is the same as the Athlon used.

And what about ev5 or ev56? Well ev6 or ev67 should be the main target
to be emulated I think...

> When Compaq bought the corpse of DEC back in the mid-90's, they weren't 
> interested in their chip designers, so AMD scooped up most of the Alpha 
> design team.  AMD then asked them "ok, if you guys were going to design an 
> x86 compatible processor, what would it look like?"  The result was the 
> Athlon back around 1997.  You could actually stick one in an Alpha 
> motherboard, and the only reason it wouldn't boot is the bios was alpha 
> machine language instead of x86 code.  Everything else was the same, because 
> it's what the designers were familiar with.

Duh. That's new to me - didn't know that yet.

> So if you slap an Alpha in a virtual x86-64 PC motherboard, you're not too 
> far 
> off.
> 
> Here's one spec:
> http://web.archive.org/web/19990913123756/http://www.unix-ag.org/Linux-Alpha/Architectures/LX164.html

Thanks for those informations!

-of

[Qemu-devel] PreP kernels boot using Qemu

[J. Mayer]

Hi all,

I've been investigating more about PreP kernel boot using Qemu and I
achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
unmodified OHW.
The issues I found in the kernel are:
- the OpenFirmware video console driver is broken in recent 2.4 kernels
and have been removed from recent 2.6 kernel
- I then decided to use the vga16fb console driver but needed to do some
patches in order to make it compile properly
- the CMOS RTC driver is not available for PPC architecture in 2.6
kernels and need some patches in order to be usable
- I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
kernels. The bugs are visible only when cross-compiling from a
little-endian and/or 64 bits host.
- I got issues (ie process freezing) when using the 2.6.22 kernel with
HZ > 100. It seems to run properly when the system timer is set to 100
Hz but this needs more tests for confirmation.
- I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
when it has no RTC available. There is no problem when the RTC is
present. This is likely to be a kernel bug: when no RTC is available, it
cannot calibrate its timers properly and the kernel timer seems to run
very fast. Forcing (with hacks...) the timer to run at nearly real-time
seems to prevent the bug to happen.

I then generated some kernels that allow me to boot and use those 3
kernels.
Here are 3 tarballs with:
- a patch to be applied to the vanilla kernel sources to fix the
mentionned bugs
- the .config file I used to build the kernel
- the zImage.prep image




I then run Qemu with the following command line template:
./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
-cpu 604 -M prep -L pc-bios/ -hda  -cdrom 
-kernel
/linux-.patched/arch/ppc/boot/images/zImage.prep

Hope this helps.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized