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

[J. Mayer]

On Mon, 2007-10-22 at 20:09 -0500, Carlo Marcelo Arenas Belon wrote:
> 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).

Then, it seems better to me to be add an option to disable the VNC
server. Why should we have a graphical output when we want to emulate
boards that don't have any kind of graphical devices ?

[...]

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

Hi,

Sorry for the delay...

On Fri, 2007-10-19 at 12:57 -0500, Milton Miller wrote: 
> On Oct 18, 2007, at 6:46 PM, J. Mayer wrote:
> > On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
[...]
> Rob was complaining he needed arch ppc to boot prep qemu but  
> kernel_headers only worked on powerpc.  Rob choose prep because the  
> header on the prep kernel was the only one that satisfied Open Hackware  
> when supplied to -kernel.  About this time Dave Gibson started code to  
> run prep hardware under powerpc.  It had several assumptions on what  
> the machine looked like.  As I remember it, I tried Dave's port on the  
> qemu 0.6.2 found on the Knoppix 4.0.2 dvd and caused qemu to segv.  I  
> was not prepared to debug qemu; I assumed the assumptions were not met.
> 
> Taking a look at Open Hackware 0.4, it appears that it treats the  
> memory given to -kernel as a block device.  That makes no sense to me.   
> I would expect it to treat the memory as the file loaded from the block  
> device.

This seems very common and useful to me to treat memory the same way you do 
with any block device. You can then have RAM disks, MTD, ... That's the idea 
behind it, even if the current implementation may not properly reflect it.
It's even more logical to treat the PreP kernel image as a bloc device as it is 
exactly a bloc device image dump...

>   Seeing that no updates to Open Hackware had been made in  
> years, and that it only pretended to have a open firmware client  
> interface and contained a mostly useless rtas (eg no pci config  
> methods), I decided to try bypassing it and just give the kernel what  
> it was looking for: a description of the hardware.

OpenFirmware should not be required to boot a PreP system, as it is only
an option of the platform. The residual data should be sufficient for
any OS, if we follow the specification. RTAS is not used on PreP, as far
as I know, it seems to be useful mostly when running in a virtual
partition but this is not supported by Qemu for now.

> 
> I choose to continue with prep because I knew the expected hardware  
> much better than pmac (the heathrow emulation).  I started by mining  
> Open Hackware 0.4 for information describing the hardware and its  
> startup.  I found the entry point was 0xfffc and after a bit of  
> experimentation I found qemu required the rom to be 512k and was read  
> only.  I found that since there were no caches I could do IO to serial  
> in real mode, which meant I didn't have to decide what to map via bats.  

I guess you found most of the useful informations, there !

[...]


> > I have to admit I never put the focus on trying to solve this issue,  
> > has
> > I usually use Mac99 or PowerPC 405 targets for tests and that PreP
> > machines are long obsolete and the heathrow target does not reflect any
> > real machine. But this is to be solved, for sure.
> 
>  From the patch description you inserted a openpic between the 8259 and  
> the cpu.  If this is true, at a minimum it will require this to be  
> described to be in the device tree for linux (or in the prep residual  
> data in general for hackware).  My qemu linux code wasn't expecting an  
> openpic so it would need to adjust; or perhaps David's kernel code  
> would now work.

There is no OpenPIC in the Qemu PreP target. There could be one, but
currently, there is only one i8259, when there should be 2, cascaded...
(maybe some of the IRQ problems we have come from the fact we don't have
this second IRQ controller ?).
The patch did add a description of what I called the 'internal PowerPC
interrupt controller', which in fact is the emulation of the PowerPC bus
interface. For the PreP target, only the 6xx bus is supported. The also
added proper connection between the Mac99 target OpenPIC controller and
the PowerPC input pins and should also provide the connection between
the i8529 output pin and the PowerPC IRQ input pin for the PreP target.
I realized some times ago that the connections between the heathrow PIC
and the PowerPC input pins are not emulated, but there seem to be more
problems in the heathrow emulation.

[]

> > If the proposed ROM image is best suitable to make PreP target run (and
> > as I don't spend a lot of time hacking OHW those days), it may also be
> > interesting to add a ppc_prep_rom.bin to the repository... In fact, it
> > was maybe not a good idea to try to use the same BIOS image on all
> > PowerPC targets...
> 
> The code has drawbacks, as I mentioned.  Its very linux specific and 
> the only error it finds is no load segement in the presumed elf header. 
>   It wouldn't be that hard to add some error checking and even print 
> error to the serial.  The code itself is not platform specific but the 
> device tree attached to it is.  As I said, we could link multiple 
> copies together (one for each platform) and search until we got the 
> right one; or just search trees based on the platform with the fixups 
> in code specific to

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

[Thiemo Seufer]

J. Mayer wrote:
> 
> 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.

For mips I chose the middle ground: The emulation is architecturally
correct but may not reflect FPU behaviour of the specific silicon.
E.g. one effect is that in certain cases the emulation computes values
close to underflow, while real hardware would throw the (mips FPU
specific) unimplemented exception.

For most cases this should be good enough, since only specialized
software will rely on a specific implementation's oddities.


Thiemo

[Qemu-devel] Add ioport statistics

[Dor Laor]

On some occaisons a VM can consume up to 100% host cpu due
to intensive portio activity. The current DEBUG_IPPORT prints
just write every access into the log file. This patch enable
ioport debug statistics so a summary of ioport access is printed
every second to the log file. This helps debugging production
problems.

Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
---
qemu/exec.c |3 ---
qemu/vl.c   |   58 ++
2 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/qemu/exec.c b/qemu/exec.c
index 3e588d5..974ac98 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -50,7 +50,6 @@
//#define DEBUG_TB_CHECK
//#define DEBUG_TLB_CHECK

-//#define DEBUG_IOPORT
//#define DEBUG_SUBPAGE

#if !defined(CONFIG_USER_ONLY)
@@ -1268,10 +1267,8 @@ CPULogItem cpu_log_items[] = {
{ CPU_LOG_PCALL, "pcall",
  "show protected mode far calls/returns/exceptions" },
#endif
-#ifdef DEBUG_IOPORT
{ CPU_LOG_IOPORT, "ioport",
  "show all i/o ports accesses" },
-#endif
{ 0, NULL, NULL },
};

diff --git a/qemu/vl.c b/qemu/vl.c
index 8dd839e..0e3aa70 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -129,6 +129,7 @@ int inet_aton(const char *cp, struct in_addr *ia);

//#define DEBUG_UNUSED_IOPORT
//#define DEBUG_IOPORT
+#define DEBUG_IOPORT_STAT

#if HOST_LONG_BITS < 64
#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
@@ -155,6 +156,9 @@ char phys_ram_file[1024];
void *ioport_opaque[MAX_IOPORTS];
IOPortReadFunc *ioport_read_table[3][MAX_IOPORTS];
IOPortWriteFunc *ioport_write_table[3][MAX_IOPORTS];
+#ifdef DEBUG_IOPORT_STAT
+uint32_t ioport_stat[MAX_IOPORTS] = {0};
+#endif
/* Note: bs_table[MAX_DISKS] is a dummy block driver if none available
   to store the VM snapshots */
BlockDriverState *bs_table[MAX_DISKS + 1], *fd_table[MAX_FD];
@@ -379,6 +383,10 @@ void cpu_outb(CPUState *env, int addr, int val)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "outb: %04x %02x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
+
ioport_write_table[0][addr](ioport_opaque[addr], addr, val);
#ifdef USE_KQEMU
if (env)
@@ -392,6 +400,9 @@ void cpu_outw(CPUState *env, int addr, int val)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "outw: %04x %04x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
ioport_write_table[1][addr](ioport_opaque[addr], addr, val);
#ifdef USE_KQEMU
if (env)
@@ -405,6 +416,9 @@ void cpu_outl(CPUState *env, int addr, int val)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "outl: %04x %08x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
ioport_write_table[2][addr](ioport_opaque[addr], addr, val);
#ifdef USE_KQEMU
if (env)
@@ -420,6 +434,9 @@ int cpu_inb(CPUState *env, int addr)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "inb : %04x %02x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
#ifdef USE_KQEMU
if (env)
env->last_io_time = cpu_get_time_fast();
@@ -435,6 +452,9 @@ int cpu_inw(CPUState *env, int addr)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "inw : %04x %04x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
#ifdef USE_KQEMU
if (env)
env->last_io_time = cpu_get_time_fast();
@@ -450,6 +470,9 @@ int cpu_inl(CPUState *env, int addr)
if (loglevel & CPU_LOG_IOPORT)
fprintf(logfile, "inl : %04x %08x\n", addr, val);
#endif
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat[addr]++;
+#endif
#ifdef USE_KQEMU
if (env)
env->last_io_time = cpu_get_time_fast();
@@ -1141,6 +1164,36 @@ static int timer_load(QEMUFile *f, void *opaque, int 
version_id)
return 0;
}

+#ifdef DEBUG_IOPORT_STAT
+QEMUTimer *ioport_stat_qtimer;
+
+static void ioport_stat_timer(void *opaque)
+{
+uint64_t curr_time;
+int i;
+
+curr_time = qemu_get_clock(vm_clock);
+qemu_mod_timer(ioport_stat_qtimer, curr_time + ticks_per_sec);
+
+if (loglevel & CPU_LOG_IOPORT) {
+fprintf(logfile, "%s: port_addr(h) access_times(d)\n", __FUNCTION__);
+for (i = 0; i < MAX_IOPORTS; i++)
+ if (ioport_stat[i]) {
+ fprintf(logfile, "%04x %d\n", i, ioport_stat[i]);
+ ioport_stat[i] = 0;
+ }
+fprintf(logfile, "%s: end stat\n", __FUNCTION__);
+}
+}
+
+static void ioport_stat_init(void)
+{
+ioport_stat_qtimer = qemu_new_timer(vm_clock, ioport_stat_timer, NULL);
+qemu_mod_timer(ioport_stat_qtimer, qemu_get_clock(vm_clock));
+}
+
+#endif
+
#ifdef _WIN32
void CALLBACK host_alarm_handler(UINT uTimerID, UINT uMsg,
 DWORD_PTR dwUser, DWORD_PTR dw1, DWORD_PTR dw2)
@@ -8738,6 +8791,11 @@ int main(int argc, char **argv)

init_timers();
init_timer_alarm();
+
+#ifdef DEBUG_IOPORT_STAT
+ioport_stat_init();
+#endif
+
qemu_aio_init();

#ifdef _WIN32
--
1.5.3

>From 5678da1976a01bc3f1

Re: [Qemu-devel] qemu alpha?

[Brian Wheeler]

On Tue, 2007-10-23 at 00:38 +0200, J. Mayer wrote:
> 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...
> 

A couple of notes/questions on Alpha emulators:

* there is an open source alpha emulator, but it seems to have stalled.
It is at:

http://www.camicom.com/index.php?option=com_content&task=blogcategory&id=8&Itemid=14

* The palcode is downloadable in one form or another from the old
digital site:

ftp://ftp.digital.com/pub/digital/Alpha/firmware

If the palcode could be emulated directly, it would make the emulation
much faster, however during OS boot, most OSes will override the palcode
settings.


* full-system hardware
All of the mid-to-late models used isa/pci, and usually used
off-the-shelf hardware.  I know the scsi controller that was supported
by default was qlogic-based (isp1020), and many systems had bog-standard
IDE controllers (cmd 646).  Some of the video cards supported directly
were generic VGA, matrox millenium, s3 trio, plus several proprietary
ones.  Ethernet tended to be Digital's 21142/21143 family.

Is there a howto for creating new devices and plugging them into an
existing system emulation?  Since all of these devices are pc
compatible, it seems like they could be written and debugged from the PC
emulation and 

[Qemu-devel] qemu/target-mips translate.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 13:15:33

Modified files:
target-mips: translate.c 

Log message:
Switch bc1any* instructions off if no MIPS-3D is implemented.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.106&r2=1.107

Re: [Qemu-devel] qemu/target-mips translate.c

[Aurelien Jarno]

Thiemo Seufer a écrit :
> CVSROOT:  /sources/qemu
> Module name:  qemu
> Changes by:   Thiemo Seufer  07/10/23 13:15:33
> 
> Modified files:
>   target-mips: translate.c 
> 
> Log message:
>   Switch bc1any* instructions off if no MIPS-3D is implemented.
> 
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.106&r2=1.107
> 

What about using:

check_insn(env, ctx, ASE_MIPS3D);

instead?

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

Re: [Qemu-devel] qemu/target-mips translate.c

[Thiemo Seufer]

Aurelien Jarno wrote:
> Thiemo Seufer a écrit :
> > CVSROOT:/sources/qemu
> > Module name:qemu
> > Changes by: Thiemo Seufer  07/10/23 13:15:33
> > 
> > Modified files:
> > target-mips: translate.c 
> > 
> > Log message:
> > Switch bc1any* instructions off if no MIPS-3D is implemented.
> > 
> > CVSWeb URLs:
> > http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.106&r2=1.107
> > 
> 
> What about using:
> 
> check_insn(env, ctx, ASE_MIPS3D);
> 
> instead?

You are right. Likewise for the MT ASE checks. I'm testing a patch for
it now.


Thiemo

[Qemu-devel] qemu/target-mips mips-defs.h translate.c transl...

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 17:04:27

Modified files:
target-mips: mips-defs.h translate.c translate_init.c 

Log message:
Use the standard ASE check for MIPS-3D and MT.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.17&r2=1.18
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.107&r2=1.108
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&r1=1.24&r2=1.25

[Qemu-devel] Re: PATCH, RFC: Slirp improvements

[Fabrice Bellard]

> I tried harder to change the SLIRP queue stuff to something saner by
> hiding the pointer access inside inlined functions. Still when I
> changed the 32 bit pointers to native 64 bit (or moved the pointers
> outside the packet), qemu crashes. Must be some devilishly hidden
> access somewhere. I already fixed one, which involved recycling port
> number fields for buffer pointers. IMHO there should be some kind of
> corporeal punishments mandated by law for writing this kind of mess.
> Maybe it would even be easier to create a new userland IP stack based
> on Linux from scratch instead of fixing this.
>
> I think I'll just commit in the log part, unless there are objections.

IMHO you should add a context in the 'struct socket' structure so that 
you can avoid adding a context in all the functions manipulating this 
structure. The same holds for mbuf.


Regards,

Fabrice.

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

[J. Mayer]

On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > 
> > 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.
> 
> For mips I chose the middle ground: The emulation is architecturally
> correct but may not reflect FPU behaviour of the specific silicon.
> E.g. one effect is that in certain cases the emulation computes values
> close to underflow, while real hardware would throw the (mips FPU
> specific) unimplemented exception.
> 
> For most cases this should be good enough, since only specialized
> software will rely on a specific implementation's oddities.

Well, what you've done for Mips is exactly what I called the "precise
emulation" and is far slower than the "fast math" emulation I got for
PowerPC. I was wrong talking about "PowerPC implementations" when I
should have said "PowerPC specification"; but there should be no
difference between the two (or it's not a PowerPC CPU...) because the
POWER/PowerPC specification describes very precisely the behavior of the
FPU.
The "fast math" model relies on the native-softmmu code and is suficient
for most applications. But there are a few instructions that should
always take care (or maybe at least reset) the FPSCR register, which is
not done in the current code.

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

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

[Aurelien Jarno]

J. Mayer a écrit :
> On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
>> J. Mayer wrote:
>>> 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.
>> For mips I chose the middle ground: The emulation is architecturally
>> correct but may not reflect FPU behaviour of the specific silicon.
>> E.g. one effect is that in certain cases the emulation computes values
>> close to underflow, while real hardware would throw the (mips FPU
>> specific) unimplemented exception.
>>
>> For most cases this should be good enough, since only specialized
>> software will rely on a specific implementation's oddities.
> 
> Well, what you've done for Mips is exactly what I called the "precise
> emulation" and is far slower than the "fast math" emulation I got for
> PowerPC. I was wrong talking about "PowerPC implementations" when I
> should have said "PowerPC specification"; but there should be no
> difference between the two (or it's not a PowerPC CPU...) because the
> POWER/PowerPC specification describes very precisely the behavior of the
> FPU.
> The "fast math" model relies on the native-softmmu code and is suficient
> for most applications. But there are a few instructions that should
> always take care (or maybe at least reset) the FPSCR register, which is
> not done in the current code.
> 

Then I guess it is what has been done on the SPARC target: after each FP
instruction, check_ieee_exceptions() is called to accumulate the IEEE
exceptions and generate real exceptions if they are enabled.

That doesn't look really complex, but I agree that could slow down a bit
the emulation. I will get a closer look in two or three weeks.

-- 
  .''`.  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 Tue, 2007-10-23 at 23:59 +0200, Aurelien Jarno wrote:
> J. Mayer a écrit :
> > On Tue, 2007-10-23 at 12:47 +0100, Thiemo Seufer wrote:
> >> J. Mayer wrote:
> >>> 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.
> >> For mips I chose the middle ground: The emulation is architecturally
> >> correct but may not reflect FPU behaviour of the specific silicon.
> >> E.g. one effect is that in certain cases the emulation computes values
> >> close to underflow, while real hardware would throw the (mips FPU
> >> specific) unimplemented exception.
> >>
> >> For most cases this should be good enough, since only specialized
> >> software will rely on a specific implementation's oddities.
> > 
> > Well, what you've done for Mips is exactly what I called the "precise
> > emulation" and is far slower than the "fast math" emulation I got for
> > PowerPC. I was wrong talking about "PowerPC implementations" when I
> > should have said "PowerPC specification"; but there should be no
> > difference between the two (or it's not a PowerPC CPU...) because the
> > POWER/PowerPC specification describes very precisely the behavior of the
> > FPU.
> > The "fast math" model relies on the native-softmmu code and is suficient
> > for most applications. But there are a few instructions that should
> > always take care (or maybe at least reset) the FPSCR register, which is
> > not done in the current code.
> > 
> 
> Then I guess it is what has been done on the SPARC target: after each FP
> instruction, check_ieee_exceptions() is called to accumulate the IEEE
> exceptions and generate real exceptions if they are enabled.
> 
> That doesn't look really complex, but I agree that could slow down a bit
> the emulation. I will get a closer look in two or three weeks.

It's not so complex. What would greatly slow down the emulation is that
you need to use the softfloat model instead of the softfloat-native one
for this to produce the expected result.
The PowerPC "fadd" instruction just compiles with 3 insns on amd64,
using the "fast math" model:
movlpd 0x1b8(%r14),%xmm0 ; /* Load env->ft0 into a MMX register */
addsd  0x1b0(%r14),%xmm0 ; /* Add env->ft1 */
movsd  %xmm0,0x1b0(%r14) ; /* Store the result into env->ft0 */
With the "precise" model, you need to:
1/ Clear the floating point flags
2/ Load operands from env->ft0 & env->ft1 into host registers
3/ Call the float64_add function
4/ Store the result into env->ft0
5/ Compute the architecture specific FPU flags
which will lead to execute much more code for each FPU operation and
will consume much more space in the TB buffer.

It's a good idea to allow the use of such a precise model, when you want
to use specific applications that rely on the FPU to properly handle
NaNs, infinities and properly generate exceptions. But, as it's not
needed by most applications, having a "fast math" model is also great to
have a quicker emulation. I said it would be great to allow the choice
of the model at compile time but it could in fact be choosen at
run-time, just tweaking the code translator (which should not lead to
any performance penalty for the "fast" model case) and compiling twice
the FPU micro-operations, once with the CONFIG_SOFTFLOAT defined, once
without. This way, the Qemu user could easily choose between "fast" or
"precise" models, just changing a switch on the command line.

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

[Qemu-devel] qemu/target-mips op.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 23:22:03

Modified files:
target-mips: op.c 

Log message:
Fix CLO calculation for MIPS64. And a small code cleanup.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.77&r2=1.78

[Qemu-devel] qemu host-utils.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 23:22:54

Modified files:
.  : host-utils.c 

Log message:
Fix overflow when multiplying two large positive numbers.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemu&r1=1.1&r2=1.2

[Qemu-devel] qemu/target-mips op_mem.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 23:23:43

Modified files:
target-mips: op_mem.c 

Log message:
Enforce proper sign extension for lwl/lwr on MIPS64.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=qemu&r1=1.14&r2=1.15

[Qemu-devel] Trying to Understand QEMU's Low Level Functionality ...

[Atoosaah S]

I'm using qemu version 0.8.2 on linux.

I'm currently successful in creating the result.txt (with the command: prof
/intsall_path/qemu gmon.out > result.txt), but the call graph created does
not show my functions of interest.

For example i'm trying to understand the sequence of calls qemu makes to
read/write from the disk image. Using print statements i see the function
ide_read_dma_cb (from hw directory, file ide.c) being called; as well as
bdrv_read from (qemu root directory, file block.c). The only ide function i
see in result.txt is ide_init2 and ide_init_ioport, and the only bdrv type
functions are bdrv_open2 and bdrv_new. But, listing the symbol table via
"nm" on qemu, does display my functions of interest (i.e. bdrv_read,
bdrv_write, ...). I should see these functions in the gprof result since,
for example, they are executed frequently (during OS bootup, and
writting/reading to/from a sample large file)

1. Why am I only seeing specific low level functions in the call graph?
2. Is there a more clear way of finding out how (i.e. sequence of calls)
qemu make to write to the disk image?

thank you,
atoosaah




On 10/12/07, Atoosaah wrote:
>
> I'd appreciate any input on how to run gprof successfully on qemu. I'm new
> to gprof and am probably missing some steps.  I successfully ran gprof on a
> sorting program available online, then I attempted to run gprof on qemu.
>
> Here are the steps I take:
>
> I'm trying to run gprof on qemu, but am unsuccessful. my os is linux, my
> qemu version is 0.8.2. I configure qemu with the options "configure
> --prefix=/install_path --enable-gprof. Then I make and make install. I run
> qemu successfully using the options /install_path/qemu -hda diskimage.img-m 
> 256 which results in the
> gmon.out file. My run of qemu involved starting the image (virtual linux
> OS), running a few simple commands and shutting the image down.
>
> Finally, I run gprof /intsall_path/qemu gmon.out > result.txt which gives
> the error: gprof: file 'qemu' has no symbols'
>
> Are there any other configuration options required? Should the image be
> run with differently?
>
>
> thank you,
> atoosaah
>

Re: [Qemu-devel] Strange behaviour

[Joe Ross]

Do you think your problems are related to either of the following Ubuntu
bugs?

https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/144368
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/154960

Joe

On 10/22/07, Christian Fontana <[EMAIL PROTECTED]> wrote:
>
> 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
>
>
>

[Qemu-devel] qemu/target-mips op.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/23 23:58:21

Modified files:
target-mips: op.c 

Log message:
Fix writable length of the index register.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.78&r2=1.79

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

[Thiemo Seufer]

J. Mayer wrote:
[snip]
> > > 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.
> > 
> > For mips I chose the middle ground: The emulation is architecturally
> > correct but may not reflect FPU behaviour of the specific silicon.
> > E.g. one effect is that in certain cases the emulation computes values
> > close to underflow, while real hardware would throw the (mips FPU
> > specific) unimplemented exception.
> > 
> > For most cases this should be good enough, since only specialized
> > software will rely on a specific implementation's oddities.
> 
> Well, what you've done for Mips is exactly what I called the "precise
> emulation" and is far slower than the "fast math" emulation I got for
> PowerPC. I was wrong talking about "PowerPC implementations" when I
> should have said "PowerPC specification"; but there should be no
> difference between the two (or it's not a PowerPC CPU...) because the
> POWER/PowerPC specification describes very precisely the behavior of the
> FPU.
>
> The "fast math" model relies on the native-softmmu code and is suficient
> for most applications. But there are a few instructions that should
> always take care (or maybe at least reset) the FPSCR register, which is
> not done in the current code.

My theory is that occasional FP users won't suffer from the performance
impact, and heavy FP users are likely to expect IEEE conformance. Thus
I gave priority to correctness.

Implementing a R8000-style fast FP mode sounds like fun, but for the
moment I have already enough unfinished bits and pieces in Qemu. :-)


Thiemo

[Qemu-devel] qemu/target-mips op.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/24 00:10:32

Modified files:
target-mips: op.c 

Log message:
Force proper sign extension for mfc0/mfhc0 on MIPS64.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.79&r2=1.80

[Qemu-devel] qemu-2007-10-24 build error

[황윤성]

gcc32  -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o console.o 
loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o block-qcow.o aes.o 
block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o 
block-qcow2.o block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o 
lsi53c895a.o usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o 
usb-wacom.o eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o 
ptimer.o etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o 
slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o slirp/ip_output.o 
slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o slirp/socket.o 
slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o slirp/tcp_timer.o 
slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o libqemu.a  -lm -lz 
-lgnutls   -L/usr/lib -lSDL -lpthread  -lrt -lutil
libqemu.a(helper.o): In function `do_interrupt':
/usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined reference to 
`__builtin_clz'
libqemu.a(translate-op.o): In function `dyngen_code':
/home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to `__builtin_clz'
libqemu.a(op.o): In function `op_lz_T0_T1':
/usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined reference to 
`__builtin_clz'
collect2: ld returned 1 exit status





Linux localhost.localdomain 2.6.19-10hs #1 Tue Apr 3 11:29:42 KST 2007 i686 
i686 i386 GNU/Linux

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
--disable-dssi --enable-plugin 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic 
--host=i386-Haansoft-linux
Thread model: posix
gcc version 4.1.1 20061120 (Haansoft 4.1.1-41)


-
Your Life on the Net
DreamWiz Free Mail @ http://www.dreamwiz.com/

[Qemu-devel] qemu/target-mips translate.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/10/24 00:52:08

Modified files:
target-mips: translate.c 

Log message:
Remove bogus instruction decode.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.108&r2=1.109

Re: [Qemu-devel] Trying to Understand QEMU's Low Level Functionality ...

[Igor Kovalenko]

On 10/24/07, Atoosaah S <[EMAIL PROTECTED]> wrote:
> I'm using qemu version 0.8.2 on linux.
>
> I'm currently successful in creating the result.txt (with the command: prof
> /intsall_path/qemu gmon.out > result.txt), but the call graph created does
> not show my functions of interest.
>
> For example i'm trying to understand the sequence of calls qemu makes to
> read/write from the disk image. Using print statements i see the function
> ide_read_dma_cb (from hw directory, file ide.c) being called; as well as
> bdrv_read from (qemu root directory, file block.c). The only ide function i
> see in result.txt is ide_init2 and ide_init_ioport, and the only bdrv type
> functions are bdrv_open2 and bdrv_new. But, listing the symbol table via
> "nm" on qemu, does display my functions of interest ( i.e. bdrv_read,
> bdrv_write, ...). I should see these functions in the gprof result since,
> for example, they are executed frequently (during OS bootup, and
> writting/reading to/from a sample large file)
>
> 1. Why am I only seeing specific low level functions in the call graph?
> 2. Is there a more clear way of finding out how (i.e. sequence of calls)
> qemu make to write to the disk image?

Try valgrind instead?
valgrind --tool=callgrind --smc-check=all -v


-- 
Kind regards,
Igor V. Kovalenko