Re: [Qemu-devel] Patch: generate a DBF when a GPF could not be delivered on x86

[Sebastian Kaliszewski]

Bernhard Kauer wrote:

Qemu does not generate a double fault (DBF) on x86, if a general protection
fault could not be delivered. Instead it hangs in a loop.

The patch fix this bug by checking whether we are already in a GPF exception.


If you're at it, maybe add triple fault handling (ie exception if DBF 
handler) -- it should reset CPU.



rgds
--
Sebastian Kaliszewski

Re: [Qemu-devel] why is kqemu closed?

[Sebastian Kaliszewski]

Auke Kok wrote:
no matter how you turn Linus' arguments, he doesn't like anything else 
than ports from windows driver objects linked, and I can really agree 
with that. Whatever the laywers say about it is moot - only judges 
listen to them and Open Source doesn't listen to laywers (in generally). 
Plenty of vendors are already backing up Open Source too, and not just 
with t-shirts and penguins.


The only thing important is what GPL says. And GPL is clear here. KQemu must 
be a derived work (i.e. include some source (even C headres) from kernel 
and/or be bound just to a Linux kernel) to be forced to go under GPL. But 
neither it includes any kernel headres nor it's Linux only -- the very same 
binary (object file) can be used with *BSD as well as Windows. So KQemu can 
be legally licenced under any licence Fabrice chooses.


rgds
--
Sebastian Kaliszewski





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

Re: [Qemu-devel] why is kqemu closed?

[Sebastian Kaliszewski]

andrzej zaborowski wrote:

Now, whether using kqemu together with a linux kernel will still be
legal is a different issue, but here the question is whether the user
is breaking the law, not the author.



And then GPL explicitly allows user to do anything (s)he wishes, including 
(but not limited to) linking with closed source software, incorporating into 
closed source software, etc. until resultant binary is used "internally" 
(i.e. is not spread further).


rgds
--
Sebastian Kaliszewski


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

Re: [Qemu-devel] [PATCH] PC speaker emulation (square wave)

[Sebastian Kaliszewski]

Joachim Henke wrote:
Ok, I simplified my patch to generate just plain square waves.  Indeed, 
its sound is much closer to a real PC speaker now.


Does "cut off frequency" mean, that we have silence above that  specific 
frequency?


No. Typical cutoff freq is where components of the signal are attenuated by 
3dB (i.e. are half as loud). At 2 times taht frequency they'll be attenuated 
by 3 + A dB, where A is filter's rate in dB/octave. Typical 1st order filter 
is 6dB/octave, 2nd order is 12dB/octave, etc. Typical soundards used no more 
than 2nd order filter.


But, if you want to have your path behave really nicely, you should simply 
not generate at all waves at frequencies above half of current output 
sampling rate -- those can't be reproducted -- instead significant 
distortion will be generated (google for Nyquist frequency).


rgds
--
Sebastian Kaliszewski


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

Re: [Qemu-devel] [PATCH] PC speaker emulation (fixed point)

[Sebastian Kaliszewski]

On Tuesday 24 January 2006 22:45, Fabrice Bellard wrote:
> If you want to model the real PC speaker, the best to do is to generate
> a square signal and to pass it thru a low pass filter with a cut off
> frequency of a few kHz. Then you could even be able to play samples thru
> the simulated PC speaker using the tricks used in old MSDOS programs,
> provided QEMU implements a precise cycle counter (it will come someday
> !).

Change that few to 15 [kHz] and that would be what some PC-speaker hooking 
SB-clones did. But there were PCs with piezoelectric speakers, and those 
could genereate sounds well above 20kHz. But yes, typically 12-15kHz cutoff 
with 1st or 2nd order filter would do the trick.

And if someone wants full reality one would also need some not-too-strong 
(1st order, 6dB/oct) hi-pass filter around 80-120Hz -- as those tiny 
PC-speakers are unable to emit bass.

rgds
-- 
Sebastian Kaliszewski


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

Re: [Qemu-devel] [PATCH] PC speaker emulation (fixed point)

[Sebastian Kaliszewski]

Joachim Henke wrote:
Ok, these are really strong arguments. Thanks a lot for your  
interesting statements! I'll do some testing on square waves and will  
post an updated patch, as I am also not totally satisfied with the  
current sound myself.


One little suggestion...

Real PC-speaker is rather poor source of sound, and I also noticed, that 
sound cards which took PC-speaker sound for themselves (some SB-clones did 
route PC-speaker sound into thier own output) liked to low-pass filter the 
resulting audio. So to make things as real as feasible, use your wave table 
to store something like square wave with rounded corners -- maybe sth like 
pow(sin(x), 0.2) (i.e. sinus rooted to 5th degree) will sound pleasant enough.


rgds
--
Sebastian Kaliszewski


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

Re: [Qemu-devel] [PATCH] PC speaker emulation (fixed point)

[Sebastian Kaliszewski]

Joachim Henke wrote:
I still prefer using a sine wave, it sounds more smooth and won't  hurt 
our ears (and speakers) too much.


Well, it sounds rather dull, and even worse, on non hi-fi computer speakers 
(which is 90% of PC users use) low frequencies (<100Hz) are simply 
unhearable (since equipment is very poor at transmitting those frequencies).
While harmonics rich square wave will be hearable, due to harmonics being 
hearable.


I don't think that people want  to 
play square waves, when they have their PC connected to their hifi  
system 


Many people connected their Apples IIs, Commodores 64s & Ataris 800s to 
their Hi-Fi equipment, and those didn't break their ears nor equipment.



(c: The main purpose of the PC speaker is to generate tones  and 
many programmers used it to play melodies. Why shouldn't we take  this 
chance to make it sound as good as we can manage it?


Exactly. No real musical instrument generates sine wawes. Moreover as 
various psyhoacustics reaserch shows, using pure sine waes changes our 
perception of chords & harmony. Then 95% of home sound equipment degrages 
and attenuates low frequencies below 40-50Hz.


If Qemu is for emulation it should emulate things as close to reality as 
feasible. Why do more work & intentionally break the close emulation, while 
it's even easier to acheive?



[snip]
However, this approach should still be sufficient for our purpose.  Most 
programs don't use too low frequencies, and if they do, people  probably 
won't notice.


Many PC games used low frequencies to emit varius buzzes and stuff (like 
engine noise). With sine wave those will be completely broken.



rgds
--
Sebastian Kaliszewski


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

Re: [Qemu-devel] [PATCH] PC speaker emulation (fixed)

[Sebastian Kaliszewski]

malc wrote:

I'd like to not one thing, namely, you are using FPU to generate the
samples. This is something Fabrice expressed dissatisfaction with. In
the case of speaker it might be feasible to switch to fixed-point
calculation.


One more note about that. PC-speaker generates just plain square wave not 
sine wave, so this would be more realistic. Then fixed point calculation (16 
bit integer part and 16 bit fractional) is easy without all those sin 
calculation.



rgds
Sebastian Kaliszewski


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

Re: [Qemu-devel] KQEMU 0.7.1 not working

[Sebastian Kaliszewski]

Pablo R. Canto wrote:

Mike Swanson wrote:


Not sure why, but dmesg says this:

kqemu: Unknown symbol __PAGE_KERNEL_EXEC
 


This patch is the solution
http://www.zarb.org/cgi-bin/viewcvs.cgi/plf/SPECS/non-free/dkms-kqemu/kqemu-0.7.1-PAGE_KERNEL_EXEC.patch?rev=1.1&view=log 


Farbice proposed this instead (and it works for me):

--- kqemu-linux.c   25 Apr 2005 22:14:39 -  1.4
+++ kqemu-linux.c   25 Jul 2005 22:17:34 -
@@ -28,7 +28,13 @@
 #define pfn_to_page(pfn) (mem_map + (pfn))
 #endif

-#ifndef PAGE_KERNEL_EXEC
+#ifdef PAGE_KERNEL_EXEC
+#if defined(__i386__)
+/* problem : i386 kernels usually don't export __PAGE_KERNEL_EXEC */
+#undef PAGE_KERNEL_EXEC
+#define PAGE_KERNEL_EXEC __pgprot(__PAGE_KERNEL & ~_PAGE_NX)
+#endif
+#else
 #define PAGE_KERNEL_EXEC PAGE_KERNEL
 #endif



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

Re: [Qemu-devel] Unknown symbol __PAGE_KERNEL_EXEC

[Sebastian Kaliszewski]

Hello!

Darryl Dixon wrote:

Well, I can confirm that this works OK.

Also, congrats Fabrice, this version of kqemu appears to work OK with 
Win 9x (I booted my Win98SE machine), and the games that I use QEMU to 
run (AoE2, Civ3, Baldurs Gate 2) all were noticeably quicker.  The 
speedup didn't seem to be as dramatic as WinXP with/without kqemu, but 
it was definitely there.


Cheers,
D


On Tue, 2005-07-26 at 07:56 +0200, Pascal Terjan wrote:


On 7/26/05, Darryl Dixon <[EMAIL PROTECTED] > wrote:

Hi All, Fabrice,

Compiling the new kqemu-0.7.1 on Fedora Core 4 with kernel
2.6.12-1.1398_FC4 gives this error:

-8<---
[EMAIL PROTECTED] kqemu]$ make
make -C /lib/modules/2.6.12-1.1398_FC4/build M=`pwd` modules
make[1]: Entering directory `/usr/src/kernels/2.6.12-1.1398_FC4-i686'
  CC [M]  /opt/src/qemu-0.7.1/kqemu/kqemu-linux.o
cp /opt/src/qemu-0.7.1/kqemu/kqemu-mod-i386.o 
/opt/src/qemu-0.7.1/kqemu/kqemu-mod.o
  LD [M]  /opt/src/qemu-0.7.1/kqemu/kqemu.o
  Building modules, stage 2.
  MODPOST
Warning: could not find /opt/src/qemu-0.7.1/kqemu/.kqemu-mod.o.cmd
for /opt/src/qemu-0.7.1/kqemu/kqemu-mod.o
*** Warning: "__PAGE_KERNEL_EXEC" [/opt/src/qemu-0.7.1/kqemu/kqemu.ko]
undefined!
  CC  /opt/src/qemu-0.7.1/kqemu/kqemu.mod.o
  LD [M]  /opt/src/qemu-0.7.1/kqemu/kqemu.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.12-1.1398_FC4-i686'


Had exactly the same problem the proposed patch seems to fix it.

rgds
Sebastian


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

Re: [Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0

[Sebastian Kaliszewski]

So the idea was indeed stupid :)

On Monday 09 May 2005 02:40, Paul Brook wrote:
> No. The main problem with gcc3.4 was that we weren't using FORCE_RET
> everywhere that we should. This has mostly been fixed now.

I see...

[snip]
>
> I've got a solution for x86/x86-64 that's 95% complete, using the method
> I suggested in a previous email. 

So, since ret is too small to be replaced with jump, you relocate the block 
following ret few bytes further, and retarget all relevant jumps?

> I hope to be submitting a patch shortly.
> I expect most other hosts (particularly the RISC based ones) to be much
> simpler to fix.

Nice.

rgds
Sebastian Kaliszewski



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

[Qemu-devel] Stupid (probably) idea wrt dyngen & gcc 3.4 & 4.0

[Sebastian Kaliszewski]

Hello!

As I understand the problem with dyngen & GCC 3.4 and newer is that even 
when using the following marcro (line 158 of dynget-exec.h) in op_* 
functions

#define FORCE_RET() asm volatile ("");

GCC still puts multiple exit points of a function.

But did anyone try the following one:

#define FORCE_RET() asm volatile ("" : : : "memory" );

This tells GCC that that asm block clobbers arbitrary memory. If it doesnt 
help, then maybe putting few instructions will help (increasing the weight 
of the code thus convincing optimiser not to multiplicate the asm block)?

#define FORCE_RET() asm volatile ("nop; nop; nop; nop" : : : "memory" );

or 

#define FORCE_RET() asm volatile ("ret; ret; ret; ret" : : : "memory" );

Then if the above fails, then simply search the binary code for such block 
of fout instructions (in case of nops it'd be 0x90909090, in case of ret's 
-- don't remember). It's rather impossible, that such immediate value would 
apear inside op_* code, so the only real possibility is FORCE_RET() 
occurence (Ther is also slim possibility that such code would be an align 
fill block -- but AFAIR gcc is instructed ther not to align code and AFAIR 
gcc would use block of 4 one byte nops -- it will use longer nops in such 
cases). So then replacing such nops with jumps to end inside blocks is 
trivial.

What do you think?

rgds
Sebastian Kaliszewski
-- 
"Never undersetimate the power of human stupidity" -- from notebooks of L.L.


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