Re: [Qemu-devel] ppc: TCG and FP exceptions, is it right ?

[Tristan Gingold]

> On 25 Jul 2016, at 11:44, Benjamin Herrenschmidt  
> wrote:
> 
> Hi folks !
> 
> I could use a bit of help determining if something is quite right in
> TCG emulation of FP ops.
> 
> Fabien, Tristan, you submitted a patch back in 2013:
> 
> db72c9f256ae70b30c5d5985234f085df4226c55 "powerpc: correctly handle fpu
> exceptions" which effectively makes any of the exceptions generated
> for underflow, overflow and inexact fire right away
> (helper_raise_exception_err will exit the cpu loop with a setjmp).
> 
> This makes them effectively do the same thing
> as float_zero_divide_excp().
> 
> However I *think* it might not be what we want, according to the
> comment in helper_float_check_status() that says
> 
>  /* Differred floating-point exception after target FPR update */
> 
> And according to the architecture definition for those exceptions,
> where we indeed want the target FPR updated before we take the
> interrupts.
> 
> The code as writte will take the exception before the FPR is updated,
> I *think*, or am I missing something here  ?

This looks like an oversight. In our tests, we don't read the fpr.

> 
> I think the intent was to return to the translated code so the FPRons
> update happen, though we ideally would need to also set some state
> so the translated code itself can then check for an exception and
> fire it.
> 
> However as you noticed, that doesn't work well either.
> 
> What do you think is the most appropriate implementation here?
> 
> I'm thinking it's almost worth bringing FE0/FE1 into the hflags
> so that we know at translation time whether to be precise, imprecise,
> or ignore FP exceptions.
> 
> Then we could do something along the lines of:
>  
>   - In the helpers, when checking status, set an env flag if an
> exception should occur.
> 
>   - In all the translate call sites, if FE0/1 is non-0 (at translate
> time), generate call to check that flag and shoot the exception
> 
>   - Optionally, we could even implement some smarts to defer this to
> the end of a TB in imprecise mode.
> 
> An additional note is that if FE0/FE1 are 0, we still in some case
> leave an exception behind in cs->exception_index. Now, I *think*
> that's ok, it will just be silently dropped at some point, but I am not
> 100% certain as that's a part of TCG I'm an not super familiar with
> yet.
> 
> What do you guys reckon ? I am missing something here ?

I like the second helper suggestion from rth@.  That's simple.

Tristan.

[Qemu-devel] [PATCH] powerpc: use float64 for frsqrte

[Tristan Gingold]

Remove the code that reduce the result to float32 as the frsqrte
instruction is defined to return a double-precision estimate of
the reciprocal square root.

Although reducing the fractional part is harmless (as the estimation
must have at least 12 bits of precision according to the old PEM),
reducing the exponent range is not correct.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 target-ppc/fpu_helper.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
index cd8f015..da93d12 100644
--- a/target-ppc/fpu_helper.c
+++ b/target-ppc/fpu_helper.c
@@ -977,7 +977,6 @@ uint64_t helper_fres(CPUPPCState *env, uint64_t arg)
 uint64_t helper_frsqrte(CPUPPCState *env, uint64_t arg)
 {
 CPU_DoubleU farg;
-float32 f32;
 
 farg.ll = arg;
 
@@ -991,8 +990,6 @@ uint64_t helper_frsqrte(CPUPPCState *env, uint64_t arg)
 }
 farg.d = float64_sqrt(farg.d, env-fp_status);
 farg.d = float64_div(float64_one, farg.d, env-fp_status);
-f32 = float64_to_float32(farg.d, env-fp_status);
-farg.d = float32_to_float64(f32, env-fp_status);
 }
 return farg.ll;
 }
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH] powerpc: use float64 for frsqrte

[Tristan Gingold]

On 03 Jun 2014, at 12:02, Alexander Graf ag...@suse.de wrote:

 On 06/03/2014 11:14 AM, Tristan Gingold wrote:
 Remove the code that reduce the result to float32 as the frsqrte
 instruction is defined to return a double-precision estimate of
 the reciprocal square root.
 
 Although reducing the fractional part is harmless (as the estimation
 must have at least 12 bits of precision according to the old PEM),
 reducing the exponent range is not correct.
 
 Signed-off-by: Tristan Gingold ging...@adacore.com
 
 I couldn't find a reference to doubles in ISA 2.07. Is frsqrte supposed to 
 return doubles on all cores?

I have just checked ISA V 2.06 (will download 2.07 if necessary).  There are 
now two
instructions: frsqrte and frsqrtes.  The second one if for single - so the 
first one is for double.

[ If you look at IBM AIX assembly manual:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/frsqrte.htm

they clearly mention that frsqrte operates on double on 603, 604 but not 
implemented on 601]

  Or is this implementation specific?

This instruction is optional and the precision of the estimation is 
implementation dependant.
I have looked at some implementation manuals (604, 603, e300) and they don't 
mention single.

 Also, is frsqrte the only instruction affected?

Yes.  Operation fres operates on single.

Tristan.

 
 
 Alex
 
 ---
  target-ppc/fpu_helper.c |3 ---
  1 file changed, 3 deletions(-)
 
 diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c
 index cd8f015..da93d12 100644
 --- a/target-ppc/fpu_helper.c
 +++ b/target-ppc/fpu_helper.c
 @@ -977,7 +977,6 @@ uint64_t helper_fres(CPUPPCState *env, uint64_t arg)
  uint64_t helper_frsqrte(CPUPPCState *env, uint64_t arg)
  {
  CPU_DoubleU farg;
 -float32 f32;
farg.ll = arg;
  @@ -991,8 +990,6 @@ uint64_t helper_frsqrte(CPUPPCState *env, uint64_t arg)
  }
  farg.d = float64_sqrt(farg.d, env-fp_status);
  farg.d = float64_div(float64_one, farg.d, env-fp_status);
 -f32 = float64_to_float32(farg.d, env-fp_status);
 -farg.d = float32_to_float64(f32, env-fp_status);
  }
  return farg.ll;
  }
 

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Tristan Gingold]

On Nov 24, 2011, at 11:44 AM, Andreas Färber wrote:

 Am 23.11.2011 22:59, schrieb Richard Henderson:
 On 11/20/2011 12:51 PM, Andreas Färber wrote:
 * Part of the problem is that common CPUState fields are not at the
 start of the struct. I have therefore been playing with a
 CPU_COMMON_PREFIX at the start of the struct and using a macro for
 clearing on reset, which preserves part of the common prefix fields.
 
 Most of the RISC hosts have a limited displacement in their load and
 store instructions.  E.g. 14 bits for Sparc, 12 bits for ARM, 10.
 We want to be able to load and store the target cpu registers very
 efficiently.
 
 If you move all the common fields to the beginning, that will include
 the (rather large) TLB tables, and overflow those small offsets.
 
 This change would almost certainly be a Large Mistake.
 
 Then what is your suggestion?

Point to the middle ?

IE, positive offsets for the common structure, negative offsets for the 
architecture defined ones.

 
 Today, common code is accessing env- struct members directly for
 icount, TLB, etc. If they're at the end of the struct, offsets vary and
 we can't cast to a common-subset struct.
 
 Anthony's qom-upstream.4 branch doesn't seem to touch CPUState yet.
 Having an empty C++ base class with virtual, non-implemented accessor
 methods that are implemented for each arch is the only solution I can
 think of other than proxy functions with large switches based on a
 common (=prefixed) type field.
 
 Andreas
 

Re: [Qemu-devel] Add option to disable Cocoa on Mac OS X

[Tristan Gingold]

On May 6, 2011, at 11:48 AM, Ben Leslie wrote:

 Hi all,
 
 Are there any objections to adding a --disable-cocoa configure option?
 For simulating ARM microcontrollers I have no desire or need for graphics.

Seconded.  I think I have once posted such a patch.

Tristan.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

[Tristan Gingold]

On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote:

 On 04/20/2011 08:46 AM, Tristan Gingold wrote:
 Right, but you could create an ev67 machine with a single PCI
 controller (or put all the devices on the same PCI controller).
 
 Even the lowly ds10 has two hoses.
 
 I'll admit I hadn't considered engineering the second hose to
 be present but always appear empty.  It's something to consider.
 
 Ah, ok I understand.  I fear that if you implement your own ISR, you will 
 only be able to boot linux...
 which I suppose is your primary target.  OTOH, it will be much faster than a 
 native ISR.
 
 Yes, Linux is the primary goal.
 
 But I suspect that if I implemented enough of CALL_PAL CSERVE,
 you could boot Tru64, or at least one of the BSDs.

BSD should be doable, but I doubt for Tru64.  Do you have technical doc about 
the SRM ?
IIRC, the SRM uses its own palcode and SRM specific pal calls.

Tristan.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

[Tristan Gingold]

On Apr 21, 2011, at 3:37 PM, Brian Wheeler wrote:

 On Thu, 2011-04-21 at 14:31 +0200, Tristan Gingold wrote:
 On Apr 20, 2011, at 5:54 PM, Richard Henderson wrote:
 
 On 04/20/2011 08:46 AM, Tristan Gingold wrote:
 Right, but you could create an ev67 machine with a single PCI
 controller (or put all the devices on the same PCI controller).
 
 Even the lowly ds10 has two hoses.
 
 I'll admit I hadn't considered engineering the second hose to
 be present but always appear empty.  It's something to consider.
 
 Ah, ok I understand.  I fear that if you implement your own ISR, you will 
 only be able to boot linux...
 which I suppose is your primary target.  OTOH, it will be much faster than 
 a native ISR.
 
 Yes, Linux is the primary goal.
 
 But I suspect that if I implemented enough of CALL_PAL CSERVE,
 you could boot Tru64, or at least one of the BSDs.
 
 BSD should be doable, but I doubt for Tru64.  Do you have technical doc 
 about the SRM ?
 IIRC, the SRM uses its own palcode and SRM specific pal calls.
 
 
 The palcode with milo was a subset of the tru64 palcode, I think.
 Looking at the arch reference manual and assuming that the calls take
 the same parameters, the only difference is that tru64 has urti -
 return from user mode trap and linux doesn't.

Yes, Linux runs on Tru64 palcode.  But the issue is booting the Tru64 kernel.

Tristan.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

[Tristan Gingold]

On Apr 19, 2011, at 5:04 PM, Richard Henderson wrote:

 Changes from v1 to v2:
  - Split patch 5 up into little pieces.  These pieces were compile
tested by applying patch 23 (Enable alpha-softmmu) out of sequence
so that both softmmu and linux-user targets were built.  But in
the end I chickened out and re-ordered the enable patch to last.
 
  - The TB-FLAGS patch is more comprehensive.  In doing the split I
noticed that we were doing funny things with AMASK that really
ought to have belonged in the TB in the first place.
 
  - The patch for unassigned addresses is more comprehensive.  I had
previously failed to do the if-deffing dance in the generic part
of QEMU.
 
  - The PALcode source is added as a submodule.

Richard,

it looks like I miss the v1.  Anyway, some random comments:

* thank you for working on that!

* sx164 is ev56 based, isn't it ?  It would be nice if cpu version specific 
code is clearly marked.
  In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to ev5. 
 Don't know about ev7.
  It would be nice if we could easily support both ev5 and ev6.

* Yes, executive and supervisor are used only by VMS (well AFAIK).  I'd like to 
support it.
  Did you try to also support the windows mmu mode ?

* Again, thank you for working on that.

Tristan.

Re: [Qemu-devel] [PATCH 00/24] Alpha system emulation, v2

[Tristan Gingold]

On Apr 20, 2011, at 4:46 PM, Richard Henderson wrote:

 On 04/20/2011 02:06 AM, Tristan Gingold wrote:
 * sx164 is ev56 based, isn't it ?  It would be nice if cpu version specific 
 code is clearly marked.
 
 Yes, but most importantly it is the most evolved of the single hose systems.
 QEMU is nowhere near ready to deal with multiple PCI host controllers, and
 multiple ISA buses.

Right, but you could create an ev67 machine with a single PCI controller (or 
put all the devices on the same
PCI controller).

 I actually planned on emulating an EV67 but using the SX164 HW.  I think the
 Linux kernel will be that forgiving...
 
  In particular (and IIRC), pal mode for ev6 is much closer to ev4 than to 
 ev5.  Don't know about ev7.
  It would be nice if we could easily support both ev5 and ev6.
 
 Ah, see, here's where there may be some confusion...
 
 I'm not implementing any of the real cpu ISRs.  I'm not using any of the real
 PALcode.  I'm implementing my own QEMU-specific ISRs and and writing my own
 PALcode, starting with MILO's PALcode but I've diverged significantly since.

Ah, ok I understand.  I fear that if you implement your own ISR, you will only 
be able to boot linux...
which I suppose is your primary target.  OTOH, it will be much faster than a 
native ISR.

Tristan.

Re: [Qemu-devel] [PATCH] cocoa: do not create a spurious window for -version

[Tristan Gingold]

On Mar 19, 2011, at 2:44 PM, Andreas Färber wrote:

 Hello Tristan,
 
 Am 15.03.2011 um 14:18 schrieb Tristan Gingold:
 
 When invoked with -version, qemu will exit just after displaying the version,
 so there is no need to create a window.
 Also handles --XXX options.
 
 Signed-off-by: Tristan Gingold ging...@adacore.com
 
 Looks good to me except for the qemu_main() indentation.

Ah.  Sorry for the nit.

 Should I fix it and enqueue it on my cocoa branch for the next pull?

Yes please.

 Just wondering, since when do we support -- options?

No idea.  Wasn't aware of that before someone else in our company used this 
flag.

Thanks,
Tristan.

 
 Andreas
 
 ---
 ui/cocoa.m |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)
 
 diff --git a/ui/cocoa.m b/ui/cocoa.m
 index 20f91bc..1ff1ac6 100644
 --- a/ui/cocoa.m
 +++ b/ui/cocoa.m
 @@ -865,10 +865,19 @@ int main (int argc, const char * argv[]) {
 
/* In case we don't need to display a window, let's not do that */
for (i = 1; i  argc; i++) {
 -if (!strcmp(argv[i], -vnc) ||
 -!strcmp(argv[i], -nographic) ||
 -!strcmp(argv[i], -curses)) {
 +const char *opt = argv[i];
 +
 +if (opt[0] == '-') {
 +/* Treat --foo the same as -foo.  */
 +if (opt[1] == '-') {
 +opt++;
 +}
 +if (!strcmp(opt, -vnc) ||
 +!strcmp(opt, -nographic) ||
 +!strcmp(opt, -version) ||
 +!strcmp(opt, -curses)) {
return qemu_main(gArgc, gArgv);
 +}
}
}
 
 -- 
 1.7.3.GIT
 
 
 

Re: [Qemu-devel] OSX build issues

[Tristan Gingold]

On Mar 17, 2011, at 11:28 AM, François Revol wrote:

 Hi,
 
 Le 16 mars 2011 à 08:57, Tristan Gingold a écrit :
 
 It should fix the build issue.
 But QEMU is unreliable on OSX even when it gets built.
 I tried to bisect but lost some time trying to find a revision that 
 actually builds. I thought I updated more this month...
 
 55f8d6ac3e03d2859393c281737f60c65dfc9ab3 definitely works ok.
 
 J'utilise ce hack pour eviter ce probleme.
 
 Indeed this hack works (quite a hack for someone working on ada :p)...

That's why I send it to you via a private mail ;-)

Note that I also get failures on Linux iirc.

 From the content of the functions called it's either one of the added fds 
 which cause problem on select() (but why ?), or likely some signal masks 
 which interfere with some internal thread in the process.
 
 I sampled the process and took some screenshots without and with the #if 0 
 hack:
 http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if0.png
 Things work but oddly what is supposed to be an internal dispatcher thread 
 ends up executing qemu code. The main thread includes lots of calls from 
 arbitrary addresses indicating it receives some signals.
 
 http://revolf.free.fr/osx/shots/shot_qemu_init_main_loop_if1.png
 Things stale, and there are 2 more threads that wait, and the main thread 
 seems quite stuck in select().

Yes, I have to investigate that...

Tristan.

[Qemu-devel] [PATCH] Autodetect clock_gettime

[Tristan Gingold]

Some POSIX OSes (such as Darwin) doesn't have clock_gettime.  This patch
falls back on gettimeofday if clock_gettime is not available.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 configure   |   11 ---
 qemu-thread-posix.c |   17 +++--
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index c18f571..6e6cd35 100755
--- a/configure
+++ b/configure
@@ -2236,17 +2236,18 @@ if compile_prog   ; then
 fi
 
 ##
-# Do we need librt
+# Do we need clock_gettime + librt
+clock_gettime=no
 cat  $TMPC EOF
-#include signal.h
 #include time.h
 int main(void) { clockid_t id; return clock_gettime(id, NULL); }
 EOF
 
 if compile_prog   ; then
-  :
+  clock_gettime=yes
 elif compile_prog  -lrt ; then
   LIBS=-lrt $LIBS
+  clock_gettime=yes
 fi
 
 if test $darwin != yes -a $mingw32 != yes -a $solaris != yes -a \
@@ -2530,6 +2531,7 @@ echo preadv support$preadv
 echo fdatasync $fdatasync
 echo madvise   $madvise
 echo posix_madvise $posix_madvise
+echo clock_gettime $clock_gettime
 echo uuid support  $uuid
 echo vhost-net support $vhost_net
 echo Trace backend $trace_backend
@@ -2679,6 +2681,9 @@ fi
 if test $fnmatch = yes ; then
   echo CONFIG_FNMATCH=y  $config_host_mak
 fi
+if test $clock_gettime = yes ; then
+  echo CONFIG_CLOCK_GETTIME=y  $config_host_mak
+fi
 if test $uuid = yes ; then
   echo CONFIG_UUID=y  $config_host_mak
 fi
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index 87c1a9f..dbe14c3 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -61,6 +61,19 @@ int qemu_mutex_trylock(QemuMutex *mutex)
 return pthread_mutex_trylock(mutex-lock);
 }
 
+static void qemu_gettime(struct timespec *ts)
+{
+#ifdef CONFIG_CLOCK_GETTIME
+clock_gettime(CLOCK_REALTIME, ts);
+#else
+struct timeval tv;
+
+gettimeofday(tv, NULL);
+ts-tv_sec = tv.tv_sec;
+ts-tv_nsec = tv.tv_usec * 1000;
+#endif
+}
+
 static void timespec_add_ms(struct timespec *ts, uint64_t msecs)
 {
 ts-tv_sec = ts-tv_sec + (long)(msecs / 1000);
@@ -76,7 +89,7 @@ int qemu_mutex_timedlock(QemuMutex *mutex, uint64_t msecs)
 int err;
 struct timespec ts;
 
-clock_gettime(CLOCK_REALTIME, ts);
+qemu_gettime(ts);
 timespec_add_ms(ts, msecs);
 
 err = pthread_mutex_timedlock(mutex-lock, ts);
@@ -144,7 +157,7 @@ int qemu_cond_timedwait(QemuCond *cond, QemuMutex *mutex, 
uint64_t msecs)
 struct timespec ts;
 int err;
 
-clock_gettime(CLOCK_REALTIME, ts);
+qemu_gettime(ts);
 timespec_add_ms(ts, msecs);
 
 err = pthread_cond_timedwait(cond-cond, mutex-lock, ts);
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] cocoa: do not create a spurious window for -version

[Tristan Gingold]

When invoked with -version, qemu will exit just after displaying the version,
so there is no need to create a window.
Also handles --XXX options.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 ui/cocoa.m |   15 ---
 1 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 20f91bc..1ff1ac6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -865,10 +865,19 @@ int main (int argc, const char * argv[]) {
 
 /* In case we don't need to display a window, let's not do that */
 for (i = 1; i  argc; i++) {
-if (!strcmp(argv[i], -vnc) ||
-!strcmp(argv[i], -nographic) ||
-!strcmp(argv[i], -curses)) {
+const char *opt = argv[i];
+
+if (opt[0] == '-') {
+/* Treat --foo the same as -foo.  */
+if (opt[1] == '-') {
+opt++;
+}
+if (!strcmp(opt, -vnc) ||
+!strcmp(opt, -nographic) ||
+!strcmp(opt, -version) ||
+!strcmp(opt, -curses)) {
 return qemu_main(gArgc, gArgv);
+}
 }
 }
 
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] Fix net_check_clients warnings: make it per vlan.

[Tristan Gingold]

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 net.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net.c b/net.c
index ddcca97..b2dfaa8 100644
--- a/net.c
+++ b/net.c
@@ -1305,9 +1305,10 @@ void net_check_clients(void)
 {
 VLANState *vlan;
 VLANClientState *vc;
-int has_nic = 0, has_host_dev = 0;
 
 QTAILQ_FOREACH(vlan, vlans, next) {
+int has_nic = 0, has_host_dev = 0;
+
 QTAILQ_FOREACH(vc, vlan-clients, next) {
 switch (vc-info-type) {
 case NET_CLIENT_TYPE_NIC:
-- 
1.7.3.GIT

[Qemu-devel] Re: [PATCH] Autodetect clock_gettime

[Tristan Gingold]

On Mar 15, 2011, at 2:34 PM, Paolo Bonzini wrote:

 On 03/15/2011 02:16 PM, Tristan Gingold wrote:
 Some POSIX OSes (such as Darwin) doesn't have clock_gettime.  This patch
 falls back on gettimeofday if clock_gettime is not available.
 
 This may be okay as a stopgap measure, but any sane porting target for QEMU 
 should have a monotonic clock.  In fact, Darwin has it.

Yes mach primitives could be used.  But why isn't a monotonic clock used on 
Linux ?  According to man, CLOCK_MONOTONIC is monotonic
while CLOCK_REALTIME isn't.

Tristan.

[Qemu-devel] Re: [PATCH] Autodetect clock_gettime

[Tristan Gingold]

On Mar 15, 2011, at 2:58 PM, Paolo Bonzini wrote:

 On 03/15/2011 02:47 PM, Tristan Gingold wrote:
 
 On Mar 15, 2011, at 2:34 PM, Paolo Bonzini wrote:
 
 On 03/15/2011 02:16 PM, Tristan Gingold wrote:
 Some POSIX OSes (such as Darwin) doesn't have clock_gettime.  This patch
 falls back on gettimeofday if clock_gettime is not available.
 
 This may be okay as a stopgap measure, but any sane porting target for QEMU 
 should have a monotonic clock.  In fact, Darwin has it.
 
 Yes mach primitives could be used.  But why isn't a monotonic clock used on 
 Linux ?  According to man, CLOCK_MONOTONIC is monotonic
 while CLOCK_REALTIME isn't.
 
 /me rereads the patch
 
 Unfortunately, pthread timed wait/lock functions are documented to use the 
 realtime clock by default.  Using pthread_condattr_setclock is probably not 
 portable enough, and anyway there is no such function for mutexes so we're 
 stuck with CLOCK_REALTIME.  What you're patching is fine, but those functions 
 might actually go away soon as they're not supported on Win32.

Fine.

 So, in addition to what you've done, you should probably use those Mach 
 primitives in qemu-timer.h.

Yes.  But note that the first aim of this patch is to make qemu compiling again 
on Darwin.

Tristan.

Re: [Qemu-devel] Re: EFI console stopped working in Qemu 0.14.0

[Tristan Gingold]

On Mar 3, 2011, at 7:43 AM, vagran wrote:

 I am using TianoCore EFI by Tristan Gingold which is published
 on http://wiki.qemu.org/download/efi-bios.tar.bz2. If you would try
 to load it on Qemu 0.14.0 (built either for i386 or x86_64) you will
 see nothing on VGA display or serial console. But it still will be
 able to load OS after timeout if you have proper disk image.

This is very old work...  AFAIK, tianocore can now produce a binary that work 
on qemu.  You'd better to switch to it.

Tristan.

[Qemu-devel] Re: [PATCH] scripts: add a guard macro in generated .h files

[Tristan Gingold]

On Feb 21, 2011, at 9:14 AM, Paolo Bonzini wrote:

 On 02/21/2011 07:42 AM, Tristan Gingold wrote:
 Mostly a style issue.  It is common to always protect header files
 against multiple inclusion, unless the header is meant to be included
 several times (which is not the case for these config files).  I
 think this is a good practice.
 
 Traditionally, autoconf's config.h headers have no guards either.  This can 
 indeed cause some troubles.  However, it also helps highlighting poor 
 practices, such as libraries installing a config.h file including it from a 
 public header.
 
 I once got redefinition warnings for macros in config-host.h, but I
 agree that adding the guard macro doesn't fix this issue.
 
 config-host.h should always be the first included header (we are poor at 
 this) and its macros should never conflict with anything else.  I think we 
 should rather fix the problems you've seen with config-host.h, if you can 
 still reproduce them.

Thank you.  I will investigate the next time I have the issue and the time.

Tristan.

Re: [Qemu-devel] [PATCH] scripts: add a guard macro in generated .h files

[Tristan Gingold]

On Feb 20, 2011, at 7:14 PM, Aurelien Jarno wrote:

 On Mon, Feb 07, 2011 at 04:21:40PM +0100, Tristan Gingold wrote:
 To avoid redefinition warnings.
 config-host.h only contains #define entries, and GCC doesn't choke when
 as long as the definitions are the same. What is the use case of this
 patch? 

Mostly a style issue.  It is common to always protect header files against 
multiple inclusion, unless the header is meant to be
included several times (which is not the case for these config files).  I think 
this is a good practice.

I once got redefinition warnings for macros in config-host.h, but I agree that 
adding the guard macro doesn't fix this issue.

If you agree that adding guards is harmless and good style, I can change the 
comment.

Tristan.

[Qemu-devel] [PATCH] Use sigwait instead of sigwaitinfo.

[Tristan Gingold]

Fix compilation failure on Darwin.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 compatfd.c |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/compatfd.c b/compatfd.c
index a7cebc4..bd377c4 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -26,45 +26,45 @@ struct sigfd_compat_info
 static void *sigwait_compat(void *opaque)
 {
 struct sigfd_compat_info *info = opaque;
-int err;
 sigset_t all;
 
 sigfillset(all);
 sigprocmask(SIG_BLOCK, all, NULL);
 
-do {
-siginfo_t siginfo;
+while (1) {
+int sig;
+int err;
 
-err = sigwaitinfo(info-mask, siginfo);
-if (err == -1  errno == EINTR) {
-err = 0;
-continue;
-}
-
-if (err  0) {
-char buffer[128];
+err = sigwait(info-mask, sig);
+if (err != 0) {
+if (errno == EINTR) {
+continue;
+} else {
+return NULL;
+}
+} else {
+struct qemu_signalfd_siginfo buffer;
 size_t offset = 0;
 
-memcpy(buffer, err, sizeof(err));
+memset(buffer, 0, sizeof(buffer));
+buffer.ssi_signo = sig;
+
 while (offset  sizeof(buffer)) {
 ssize_t len;
 
-len = write(info-fd, buffer + offset,
+len = write(info-fd, (char *)buffer + offset,
 sizeof(buffer) - offset);
 if (len == -1  errno == EINTR)
 continue;
 
 if (len = 0) {
-err = -1;
-break;
+return NULL;
 }
 
 offset += len;
 }
 }
-} while (err = 0);
-
-return NULL;
+}
 }
 
 static int qemu_signalfd_compat(const sigset_t *mask)
-- 
1.7.3.GIT

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.

[Tristan Gingold]

On Feb 18, 2011, at 4:34 PM, Jan Kiszka wrote:
 
 This and the above handling of sigwait return codes changes the error
 handling strategy.

Did it ?  I don't think so.

 So far we silently skipped errors, now we silently
 terminate the compatfd thread. I think none of both approaches is good.

I think that both silently terminate the compatfd.  The previous code is:

  do {
siginfo_t siginfo;

err = sigwaitinfo(info-mask, siginfo);
if (err == -1  errno == EINTR) {
err = 0;
continue;
}

if (err  0) {
char buffer[128];
size_t offset = 0;

memcpy(buffer, err, sizeof(err));
while (offset  sizeof(buffer)) {
ssize_t len;

len = write(info-fd, buffer + offset,
sizeof(buffer) - offset);
if (len == -1  errno == EINTR)
continue;

if (len = 0) {
err = -1;
break;
}

offset += len;
}
}
} while (err = 0);

So in case of any error, err is set to a negative value which exits the thread.

 Failing sigwait is likely a reason to bail out, but loudly, writing some
 error message to the console and triggering a shutdown of qemu.

I agree with that.

 An overflow of the compatfd pipe to the main thread may be due to some
 very unfortunate overload scenario. Not sure if that qualifies for a
 thread termination (definitely not for a silent one).

What do you mean by overflow ?  Unless I am wrong, the fd is not non-blocking, 
write will block.

 Error handling should probably be adjusted independently of this darwin
 build fix.

I agree too.

Tristan.

[Qemu-devel] [PATCH] Use sigwait instead og sigwaitinfo.

[Tristan Gingold]

Fix compilation failure on Darwin.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 compatfd.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/compatfd.c b/compatfd.c
index a7cebc4..5f7f355 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -33,9 +33,9 @@ static void *sigwait_compat(void *opaque)
 sigprocmask(SIG_BLOCK, all, NULL);
 
 do {
-siginfo_t siginfo;
+int sig;
 
-err = sigwaitinfo(info-mask, siginfo);
+err = sigwait(info-mask, sig);
 if (err == -1  errno == EINTR) {
 err = 0;
 continue;
-- 
1.7.3.GIT

[Qemu-devel] [PATCHv2] Handle icount for powerpc tbl/tbu/decr load and store.

[Tristan Gingold]

Handle option '-icount X' on powerpc targets.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 target-ppc/translate_init.c |   42 ++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 907535e..27aff74 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -154,12 +154,26 @@ static void spr_read_ureg (void *opaque, int gprn, int 
sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_read_decr (void *opaque, int gprn, int sprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_load_decr(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 
 static void spr_write_decr (void *opaque, int sprn, int gprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_store_decr(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 #endif
 
@@ -167,12 +181,26 @@ static void spr_write_decr (void *opaque, int sprn, int 
gprn)
 /* Time base */
 static void spr_read_tbl (void *opaque, int gprn, int sprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_load_tbl(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 
 static void spr_read_tbu (void *opaque, int gprn, int sprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_load_tbu(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 
 __attribute__ (( unused ))
@@ -190,12 +218,26 @@ static void spr_read_atbu (void *opaque, int gprn, int 
sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_write_tbl (void *opaque, int sprn, int gprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_store_tbl(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 
 static void spr_write_tbu (void *opaque, int sprn, int gprn)
 {
+if (use_icount) {
+gen_io_start();
+}
 gen_helper_store_tbu(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+gen_stop_exception(opaque);
+}
 }
 
 __attribute__ (( unused ))
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] ppc: init_excp_7x0: fix hreset entry point.

[Tristan Gingold]

From: gingold gingold@020d506d-db78-4e55-b2a8-6c851f84c332

According to the PowePC 750 user's manual, the vector offset for system reset
(both /HRESET and /SRESET) is 0x00100.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 target-ppc/translate_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 5d856f5..907535e 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -2925,7 +2925,7 @@ static void init_excp_7x0 (CPUPPCState *env)
 env-excp_vectors[POWERPC_EXCP_THERM]= 0x1700;
 env-hreset_excp_prefix = 0xUL;
 /* Hardware reset vector */
-env-hreset_vector = 0xFFFCUL;
+env-hreset_vector = 0xFFF00100UL;
 #endif
 }
 
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] gdbstub/ppc: handle read and write of fpscr

[Tristan Gingold]

From: Fabien Chouteau chout...@adacore.com

Although the support of this register may be uncomplete, there are no
reason to prevent the debugger from reading or writing it.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 gdbstub.c   |5 +++--
 target-ppc/translate_init.c |5 ++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 5c9a1c9..70870fb 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -722,7 +722,7 @@ static int cpu_gdb_read_register(CPUState *env, uint8_t 
*mem_buf, int n)
 {
 if (gdb_has_xml)
 return 0;
-GET_REG32(0); /* fpscr */
+GET_REG32(env-fpscr);
 }
 }
 }
@@ -770,7 +770,8 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t 
*mem_buf, int n)
 /* fpscr */
 if (gdb_has_xml)
 return 0;
-return 4;
+env-fpscr = ldtul_p(mem_buf);
+return sizeof(target_ulong);
 }
 }
 return 0;
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index dfcd949..5d856f5 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -9381,8 +9381,7 @@ static int gdb_get_float_reg(CPUState *env, uint8_t 
*mem_buf, int n)
 return 8;
 }
 if (n == 32) {
-/* FPSCR not implemented  */
-memset(mem_buf, 0, 4);
+stl_p(mem_buf, env-fpscr);
 return 4;
 }
 return 0;
@@ -9395,7 +9394,7 @@ static int gdb_set_float_reg(CPUState *env, uint8_t 
*mem_buf, int n)
 return 8;
 }
 if (n == 32) {
-/* FPSCR not implemented  */
+env-fpscr = ldl_p(mem_buf);
 return 4;
 }
 return 0;
-- 
1.7.3.GIT

Re: [Qemu-devel] [PATCH] gdbstub/ppc: handle read and write of fpscr

[Tristan Gingold]

On Feb 15, 2011, at 11:22 AM, Peter Maydell wrote:

 On 15 February 2011 08:59, Tristan Gingold ging...@adacore.com wrote:
 @@ -770,7 +770,8 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t 
 *mem_buf, int n)
 /* fpscr */
 if (gdb_has_xml)
 return 0;
 -return 4;
 +env-fpscr = ldtul_p(mem_buf);
 +return sizeof(target_ulong);
 }
 }
 return 0;
 
 Not a PPC expert, but this doesn't look right; for instance if you change
 the rounding mode by fiddling with the FPSCR in the debugger this
 won't update the softfloat rounding mode settings. (that is, it lets the
 visible state in env-fpscr get out of sync with the hidden state of the
 model). Also we probably shouldn't be letting the debugger change
 reserved fpscr bits.

Indeed, you're right.  We initially were interested in reading fpscr, and I 
wrote the writing part without thinking enough.

Tristan.

[Qemu-devel] Ping: [PATCH] Handle icount for powerpc tbl/tbu/decr load and store.

[Tristan Gingold]

Potential reviewers CC:

On Feb 8, 2011, at 10:59 AM, Tristan Gingold wrote:

 Handle option '-icount X' on powerpc targets.
 
 Signed-off-by: Tristan Gingold ging...@adacore.com
 ---
 target-ppc/translate_init.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)
 
 diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
 index 907535e..7ef86ad 100644
 --- a/target-ppc/translate_init.c
 +++ b/target-ppc/translate_init.c
 @@ -154,12 +154,24 @@ static void spr_read_ureg (void *opaque, int gprn, int 
 sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_read_decr (void *opaque, int gprn, int sprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_load_decr(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 
 static void spr_write_decr (void *opaque, int sprn, int gprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_store_decr(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 #endif
 
 @@ -167,12 +179,24 @@ static void spr_write_decr (void *opaque, int sprn, int 
 gprn)
 /* Time base */
 static void spr_read_tbl (void *opaque, int gprn, int sprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_load_tbl(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 
 static void spr_read_tbu (void *opaque, int gprn, int sprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_load_tbu(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 
 __attribute__ (( unused ))
 @@ -190,12 +214,24 @@ static void spr_read_atbu (void *opaque, int gprn, int 
 sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_write_tbl (void *opaque, int sprn, int gprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_store_tbl(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 
 static void spr_write_tbu (void *opaque, int sprn, int gprn)
 {
 +if (use_icount)
 +gen_io_start();
 gen_helper_store_tbu(cpu_gpr[gprn]);
 +if (use_icount) {
 +gen_io_end();
 + gen_stop_exception(opaque);
 +}
 }
 
 __attribute__ (( unused ))
 -- 
 1.7.3.GIT
 
 

[Qemu-devel] Re: Ping: [PATCH] Handle icount for powerpc tbl/tbu/decr load and store.

[Tristan Gingold]

On Feb 14, 2011, at 12:46 PM, Edgar E. Iglesias wrote:

 On Mon, Feb 14, 2011 at 12:34:05PM +0100, Alexander Graf wrote:
 Tristan Gingold wrote:
 Potential reviewers CC:
 
 On Feb 8, 2011, at 10:59 AM, Tristan Gingold wrote:
 
 
 Handle option '-icount X' on powerpc targets.
 
 Signed-off-by: Tristan Gingold ging...@adacore.com
 
 
 Braces are broken. Edgar knows his way around icount a lot better than
 me - I've never actually used it. Edgar, any comments?
 
 AFAICS, the patch looks OK (except for the indentation).

Thanks.  New version soon.

Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))

[Tristan Gingold]

On Feb 11, 2011, at 1:47 PM, Paolo Bonzini wrote:
 ps: HP-UX also uses IL32 on ia64.  Now _that_ is hard to understand.

Backward compatibility with hppa...

VMS also uses IL32 on alpha and ia64, but it has both P32 and P64.

Re: [Qemu-devel] [PATCH] Make tb_alloc static.

[Tristan Gingold]

On Wed, Feb 09, 2011 at 07:52:52PM +0100, Aurelien Jarno wrote:
 
 What about moving tb_alloc() (with tb_free()) higher in the file? After
 all it make sense to have the function creating or destructing a tb
 before the function manipulating them.

Thanks.  Like this ?

Tristan.


This function is only used within exec.c, so no need to make it public.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 exec-all.h |1 -
 exec.c |   52 ++--
 2 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/exec-all.h b/exec-all.h
index 81497c0..c062693 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -182,7 +182,6 @@ static inline unsigned int tb_phys_hash_func(tb_page_addr_t 
pc)
 return (pc  2)  (CODE_GEN_PHYS_HASH_SIZE - 1);
 }
 
-TranslationBlock *tb_alloc(target_ulong pc);
 void tb_free(TranslationBlock *tb);
 void tb_flush(CPUState *env);
 void tb_link_page(TranslationBlock *tb,
diff --git a/exec.c b/exec.c
index 477199b..9a7a752 100644
--- a/exec.c
+++ b/exec.c
@@ -649,6 +649,32 @@ void cpu_exec_init(CPUState *env)
 #endif
 }
 
+/* Allocate a new translation block. Flush the translation buffer if
+   too many translation blocks or too much generated code. */
+static TranslationBlock *tb_alloc(target_ulong pc)
+{
+TranslationBlock *tb;
+
+if (nb_tbs = code_gen_max_blocks ||
+(code_gen_ptr - code_gen_buffer) = code_gen_buffer_max_size)
+return NULL;
+tb = tbs[nb_tbs++];
+tb-pc = pc;
+tb-cflags = 0;
+return tb;
+}
+
+void tb_free(TranslationBlock *tb)
+{
+/* In practice this is mostly used for single use temporary TB
+   Ignore the hard cases and just back up if this TB happens to
+   be the last one generated.  */
+if (nb_tbs  0  tb == tbs[nb_tbs - 1]) {
+code_gen_ptr = tb-tc_ptr;
+nb_tbs--;
+}
+}
+
 static inline void invalidate_page_bitmap(PageDesc *p)
 {
 if (p-code_bitmap) {
@@ -1227,32 +1253,6 @@ static inline void tb_alloc_page(TranslationBlock *tb,
 #endif /* TARGET_HAS_SMC */
 }
 
-/* Allocate a new translation block. Flush the translation buffer if
-   too many translation blocks or too much generated code. */
-TranslationBlock *tb_alloc(target_ulong pc)
-{
-TranslationBlock *tb;
-
-if (nb_tbs = code_gen_max_blocks ||
-(code_gen_ptr - code_gen_buffer) = code_gen_buffer_max_size)
-return NULL;
-tb = tbs[nb_tbs++];
-tb-pc = pc;
-tb-cflags = 0;
-return tb;
-}
-
-void tb_free(TranslationBlock *tb)
-{
-/* In practice this is mostly used for single use temporary TB
-   Ignore the hard cases and just back up if this TB happens to
-   be the last one generated.  */
-if (nb_tbs  0  tb == tbs[nb_tbs - 1]) {
-code_gen_ptr = tb-tc_ptr;
-nb_tbs--;
-}
-}
-
 /* add a new TB and link it to the physical page tables. phys_page2 is
(-1) to indicate that only one page contains the TB. */
 void tb_link_page(TranslationBlock *tb,
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] Handle icount for powerpc tbl/tbu/decr load and store.

[Tristan Gingold]

Handle option '-icount X' on powerpc targets.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 target-ppc/translate_init.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 907535e..7ef86ad 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -154,12 +154,24 @@ static void spr_read_ureg (void *opaque, int gprn, int 
sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_read_decr (void *opaque, int gprn, int sprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_load_decr(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 
 static void spr_write_decr (void *opaque, int sprn, int gprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_store_decr(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 #endif
 
@@ -167,12 +179,24 @@ static void spr_write_decr (void *opaque, int sprn, int 
gprn)
 /* Time base */
 static void spr_read_tbl (void *opaque, int gprn, int sprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_load_tbl(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 
 static void spr_read_tbu (void *opaque, int gprn, int sprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_load_tbu(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 
 __attribute__ (( unused ))
@@ -190,12 +214,24 @@ static void spr_read_atbu (void *opaque, int gprn, int 
sprn)
 #if !defined(CONFIG_USER_ONLY)
 static void spr_write_tbl (void *opaque, int sprn, int gprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_store_tbl(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 
 static void spr_write_tbu (void *opaque, int sprn, int gprn)
 {
+if (use_icount)
+gen_io_start();
 gen_helper_store_tbu(cpu_gpr[gprn]);
+if (use_icount) {
+gen_io_end();
+   gen_stop_exception(opaque);
+}
 }
 
 __attribute__ (( unused ))
-- 
1.7.3.GIT

Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Tristan Gingold]

On Feb 8, 2011, at 6:58 PM, Anthony Liguori wrote:

 On 02/08/2011 04:06 AM, Aurelien Jarno wrote:
 Yes, it's slow. But is it a problem? You assume that people use QEMU
 only for emulating SMP platforms. This is a wrong assumption. Beside the
 x86 target, only sparc really supports SMP emulation.
   
 
 It's *not* just about performance.
 
 TCG requires a signal to break out of a tight chained TB loop.  If you have a 
 guest in a tight loop waiting for something external (like polling on a 
 in-memory flag), the device emulation will not get to run until a signal is 
 fired.
 
 Unless you set SIGIO on every file descriptor that selects polls on (and you 
 can't because there are a number that just don't support SIGIO), then you 
 have a race condition.

A race condition ?  Looks like you are describing a dead-lock.

But the dead lock doesn't happen because of the timer which periodically exits 
from TCG.  Hence the performance issue.

 This can be fixed by running TCG in a separate thread than select() and 
 sending a signal to the TCG VCPU when select() returns (effectively SIGIO in 
 userspace).
 
 This is exactly what the I/O thread does.


(Nobody was able to make it working on Windows - or nobody was interested in ?)

Tristan.

[Qemu-devel] [PATCH] Make tb_alloc static.

[Tristan Gingold]

This function is only used within exec.c, so no need to make it public.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 exec-all.h |1 -
 exec.c |4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/exec-all.h b/exec-all.h
index 81497c0..c062693 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -182,7 +182,6 @@ static inline unsigned int tb_phys_hash_func(tb_page_addr_t 
pc)
 return (pc  2)  (CODE_GEN_PHYS_HASH_SIZE - 1);
 }
 
-TranslationBlock *tb_alloc(target_ulong pc);
 void tb_free(TranslationBlock *tb);
 void tb_flush(CPUState *env);
 void tb_link_page(TranslationBlock *tb,
diff --git a/exec.c b/exec.c
index 477199b..1c59d0b 100644
--- a/exec.c
+++ b/exec.c
@@ -221,6 +221,8 @@ static int tlb_flush_count;
 static int tb_flush_count;
 static int tb_phys_invalidate_count;
 
+static TranslationBlock *tb_alloc(target_ulong pc);
+
 #ifdef _WIN32
 static void map_exec(void *addr, long size)
 {
@@ -1229,7 +1231,7 @@ static inline void tb_alloc_page(TranslationBlock *tb,
 
 /* Allocate a new translation block. Flush the translation buffer if
too many translation blocks or too much generated code. */
-TranslationBlock *tb_alloc(target_ulong pc)
+static TranslationBlock *tb_alloc(target_ulong pc)
 {
 TranslationBlock *tb;
 
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] qemu-timer.c: fix build on windows.

[Tristan Gingold]

The function qemu_next_alarm_deadline is needed by windows.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 qemu-timer.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 658f637..f81300b 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -708,8 +708,6 @@ int64_t qemu_next_deadline(void)
 return delta;
 }
 
-#ifndef _WIN32
-
 static int64_t qemu_next_alarm_deadline(void)
 {
 int64_t delta;
@@ -737,6 +735,7 @@ static int64_t qemu_next_alarm_deadline(void)
 return delta;
 }
 
+#ifndef _WIN32
 #if defined(__linux__)
 
 #define RTC_FREQ 1024
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] configure: allow user to override cflags.

[Tristan Gingold]

In order to allow user to override cflags, predefined flags must be inserted
before user cflags.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 configure |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 598e8e1..f18ed0d 100755
--- a/configure
+++ b/configure
@@ -939,8 +939,10 @@ cat  $TMPC  EOF
 int main(void) { return 0; }
 EOF
 for flag in $gcc_flags; do
-if compile_prog -Werror $QEMU_CFLAGS -Werror $flag ; then
-   QEMU_CFLAGS=$QEMU_CFLAGS $flag
+if compile_prog -Werror $flag $QEMU_CFLAGS  ; then
+# Note: flag must be prepended so that they could be overriden by
+# user flags (such as -fno-stack-protector)
+   QEMU_CFLAGS=$flag $QEMU_CFLAGS
 fi
 done
 
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] scripts: add a guard macro in generated .h files

[Tristan Gingold]

To avoid redefinition warnings.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 rules.mak |2 +-
 scripts/create_config |   12 
 2 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/rules.mak b/rules.mak
index ed59c9e..fb38f96 100644
--- a/rules.mak
+++ b/rules.mak
@@ -57,7 +57,7 @@ find-in-path = $(if $(find-string /, $1), \
@test -f $@ || cp $ $@
 
 %.h-timestamp: %.mak
-   $(call quiet-command, sh $(SRC_PATH)/scripts/create_config  $  $@,  
 GEN   $*.h)
+   $(call quiet-command, sh $(SRC_PATH)/scripts/create_config $*  $  
$@,   GEN   $*.h)
@cmp $@ $*.h /dev/null 21 || cp $@ $*.h
 
 # will delete the target of a rule if commands exit with a nonzero exit status
diff --git a/scripts/create_config b/scripts/create_config
index 0098e68..0302eab 100755
--- a/scripts/create_config
+++ b/scripts/create_config
@@ -1,7 +1,17 @@
 #!/bin/sh
 
+if [ $# -ne 1 ]; then
+  echo Usage: $0 filename 21
+  exit 1
+fi
+
+cond_macro=`echo $1 | tr a-z- A-Z_`_H
+
 echo /* Automatically generated by create_config - do not modify */
 
+echo #ifndef $cond_macro
+echo #define $cond_macro
+
 while read line; do
 
 case $line in
@@ -101,3 +111,5 @@ case $line in
 esac
 
 done # read
+
+echo #endif /* $cond_macro */
-- 
1.7.3.GIT

Re: [Qemu-devel] [PATCH] configure: allow user to override cflags.

[Tristan Gingold]

On Feb 7, 2011, at 4:08 PM, Markus Armbruster wrote:

 Anthony Liguori anth...@codemonkey.ws writes:
 
 On 02/07/2011 08:05 AM, Tristan Gingold wrote:
 In order to allow user to override cflags, predefined flags must be inserted
 before user cflags.
 
 Signed-off-by: Tristan Gingoldging...@adacore.com
 
 
 I think there's a very specific reason we do it this way but I cannot
 remember at the moment.
 
 Commit 1e027be7e91d854d7a0132e4a32bdf222c33dcfe perhaps?

Ah, thanks.  I then have to deal with -Wall.

Tristan.

[Qemu-devel] [PATCH] isa-bus.c: use hw_error instead of fprintf

[Tristan Gingold]

Minor clean-up in isa-bus.c.  Using hw_error is more consistent.
There is a difference however: hw_error dumps the cpu state.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 hw/isa-bus.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..3a6c961 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -68,12 +68,10 @@ void isa_bus_irqs(qemu_irq *irqs)
 qemu_irq isa_reserve_irq(int isairq)
 {
 if (isairq  0 || isairq  15) {
-fprintf(stderr, isa irq %d invalid\n, isairq);
-exit(1);
+hw_error(isa irq %d invalid, isairq);
 }
 if (isabus-assigned  (1  isairq)) {
-fprintf(stderr, isa irq %d already assigned\n, isairq);
-exit(1);
+hw_error(isa irq %d already assigned, isairq);
 }
 isabus-assigned |= (1  isairq);
 return isabus-irqs[isairq];
@@ -83,8 +81,7 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
 {
 assert(dev-nirqs  ARRAY_SIZE(dev-isairq));
 if (isabus-assigned  (1  isairq)) {
-fprintf(stderr, isa irq %d already assigned\n, isairq);
-exit(1);
+hw_error(isa irq %d already assigned, isairq);
 }
 isabus-assigned |= (1  isairq);
 dev-isairq[dev-nirqs] = isairq;
@@ -115,7 +112,7 @@ ISADevice *isa_create(const char *name)
 DeviceState *dev;
 
 if (!isabus) {
-hw_error(Tried to create isa device %s with no isa bus present.\n,
+hw_error(Tried to create isa device %s with no isa bus present.,
  name);
 }
 dev = qdev_create(isabus-qbus, name);
-- 
1.7.3.GIT

Re: [Qemu-devel] Unmaintained QEMU builds

[Tristan Gingold]

On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:

 Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
 
 On 09/05/2010 10:10 AM, Avi Kivity wrote:
 As a baby step, is there any chance of publishing an automatic nightly 
 Windows (cross-)build as a .zip file on qemu.org? That might give more 
 users a chance of detecting runtime faults during the development cycle.
 
 That's doable and useful, yes.
 
 I doubt it's useful.
 
 [...] We don't have myriads of users demanding better Windows support.  
 Search the list, there's almost no one asking questions about Windows [...]
 
 Right. There's some more recent posts on that QEMU forum, although buried 
 beneath a pile of spam.
 
 Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor Win64) 
 contributions, there's a guesstimated minor number of users. Many of us 
 including myself don't really care about the platform. When some Windows user 
 does show up and reports an error against QEMU Manager v7.0, we have no clue 
 what QEMU exactly that is based on, how it was compiled and whether there may 
 be downstream patches involved, so we're not of much help. Nobody that I 
 remember ever came up with git-bisect results to pinpoint where/how their 
 regression was introduced.

We use qemu on windows.  But in fact all our work is currently based on qemu 
0.11.

But we don't use qemu like most of you: we mostly care about ppc, we don't care 
about the bios (we directly run our executables) and
we run without vga card (serial line is fine for us).  This configuration works 
(or maybe worked) pretty well.

When qemu 0.13 will be available, we will try to port our patchset on both 0.13 
and head.  We also plan to submit some of our patches.
Then we will try to more closely follow the development.

Tristan.

Re: [Qemu-devel] Unmaintained QEMU builds

[Tristan Gingold]

On Sep 7, 2010, at 12:22 PM, Alexander Graf wrote:

 
 On 07.09.2010, at 09:38, Tristan Gingold wrote:
 
 
 On Sep 7, 2010, at 12:44 AM, Andreas Färber wrote:
 
 Am 05.09.2010 um 17:57 schrieb Anthony Liguori:
 
 On 09/05/2010 10:10 AM, Avi Kivity wrote:
 As a baby step, is there any chance of publishing an automatic nightly 
 Windows (cross-)build as a .zip file on qemu.org? That might give more 
 users a chance of detecting runtime faults during the development cycle.
 
 That's doable and useful, yes.
 
 I doubt it's useful.
 
 [...] We don't have myriads of users demanding better Windows support.  
 Search the list, there's almost no one asking questions about Windows [...]
 
 Right. There's some more recent posts on that QEMU forum, although buried 
 beneath a pile of spam.
 
 Anyway, it's a chicken-and-egg problem. There's not much Win32 (nor Win64) 
 contributions, there's a guesstimated minor number of users. Many of us 
 including myself don't really care about the platform. When some Windows 
 user does show up and reports an error against QEMU Manager v7.0, we have 
 no clue what QEMU exactly that is based on, how it was compiled and whether 
 there may be downstream patches involved, so we're not of much help. Nobody 
 that I remember ever came up with git-bisect results to pinpoint where/how 
 their regression was introduced.
 
 We use qemu on windows.  But in fact all our work is currently based on qemu 
 0.11.
 
 But we don't use qemu like most of you: we mostly care about ppc, we don't 
 care about the bios (we directly run our executables) and
 we run without vga card (serial line is fine for us).  This configuration 
 works (or maybe worked) pretty well.
 
 Mind if I ask what exactly you're trying to emulate there?

Sure.  As a compiler vendor, we use qemu to do testing for our bare-board ppc 
compiler.
We also use qemu to run tests under vxworks 5, 6, 653 and mils.

 Alex
 
 When qemu 0.13 will be available, we will try to port our patchset on both 
 0.13 and head.  We also plan to submit some of our patches.
 Then we will try to more closely follow the development.
 
 That sounds great.
 
 Overall, I think all we lack is someone who feels responsible for Windows. 
 And that person should be the maintainer and whenever something needs to be 
 done wrt Windows, it's his field. We do the same for BSD (blue swirl) and 
 pretty much OSX (Andreas and me). The real missing point here is someone who 
 feels responsible.

I see.

Tristan.

Re: [Qemu-devel] [PATCH 1/3] remove dead code from target-i386/exec.h

[Tristan Gingold]

On Jan 15, 2010, at 8:56 AM, Paolo Bonzini wrote:

 These are unused since edea5f0 (no need to define global registers in
 cpu-exec.c, 2008-05-10).

Why not removing env_to_regs and regs_to_env ?

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

[Tristan Gingold]

On Jan 6, 2010, at 6:04 PM, Andreas Färber wrote:

 
 Am 06.01.2010 um 17:29 schrieb Richard Henderson:
 
 since (1) ROMs other than the few supported by MILO are probably not 
 redistributable
 
 Tristan's trick here was to provide a way for the user to extract a 
 non-distributable ROM. I fear the controversy of whether this should be in 
 qemu-system-alpha or not kept the patch series from being committed.

No.  This point was not discussed.  It is always possible to use another ROM.
I didn't continue this work because I hadn't had the time.

The ROM is indeed an issue.  MILO is a possible solution, but is not available 
on 21264 and can only boot
linux.  I am not even sure it is still supported.
As I was mostly interested in Tru64 and VMS, I took the SRM way.  Note that a 
SRM rescue files are
available from hp.com site (which doesn't mean it is legal) and was already 
used in another es40 free
emulator.

I really don't plan to write a ROM for Alpha!

Although for performance it can make sense to emulate PAL when the OS is 
running.

 I would be delighted to see your es40 patches...
 
 v4: http://lists.nongnu.org/archive/html/qemu-devel/2009-03/msg01541.html
 
 See also http://repo.or.cz/w/qemu/es40.git
 
 Since that series added devices necessary for system emulation I assume that 
 parts of it need to be converted to the new qdev infrastructure.

Right.  This is not very recent.
IIRC, I could reach a bash prompt, but I don't remember which kernel (2.2 or 
2.6) I use.
SRM was working, as well as AlphaBIOS.
VMS bootloader crash very early.  Maybe your alpha cpu fix could improve the 
situation.
Tru64 crashed during boot.  IOTLB was not supported in qemu.
Windows crashed during boot too.

Tristan.

Re: [Qemu-devel] [PATCH 3/6] target-alpha: Reduce internal processor registers for user-mode.

[Tristan Gingold]

On Jan 4, 2010, at 8:19 PM, Richard Henderson wrote:

 The existing set of IPRs is totally irrelevant to user-mode emulation.
 Indeed, they most are irrelevant to implementing kernel-mode emulation,
 and would only be relevant to PAL-mode emulation, which I suspect that
 no one will ever attempt.

Interesting, that's the approach I used to emulate an es40 (ie full emulation 
of 21264).
This had the advantage to be able to use the genuine ROM.

Tristan.

Re: [Qemu-devel] [Bug] qemu-system-ppc: Bad clock read when started with -icount auto

[Tristan Gingold]

On Dec 29, 2009, at 4:30 PM, Stefan Weil wrote:

 Hi,
 
 When qemu-system-ppc is started with argument -icount auto
 (needed for running qemu in the emulated system),
 it will print lots of Bad clock read on stderr.
 
 env-can_do_io toggles between 0 and 1.

I have a patch to enable -icount on powerpc.  I plan to submit it shortly.  Are 
you in the hurry ?

Re: [Qemu-devel] [PATCH 0/7] Improve alpha-linux userspace emulation

[Tristan Gingold]

On Dec 10, 2009, at 1:05 AM, Richard Henderson wrote:

 
 The following patch series results in an emulator that's good enough
 to run a good bit of the GCC testsuite, dynamic linking and all.
 There are more failures than native hardware.  At first glance they
 appear to be fpu related, but I havn't investigated properly yet.

Richard,

just in case you weren't aware and are interested: I was able to make an es40 
emulation in qemu good enough
to start Linux.  I did this work several months ago, so it need revival.
At this time the main limitation was the absence of IOMMU abstraction in qemu.

Tristan.

[Qemu-devel] PATCH: minor simplification in ide.c

[Tristan Gingold]

Hi,

there is no need to alloc and free a buffer in guess_disk_lchs.   
io_buffer can be used instead.

This slightly simplify the code.




ide.diff
Description: Binary data

Re: [Qemu-devel] EFI BIOS on QEMU

[Tristan Gingold]

On Jan 7, 2008, at 9:19 PM, Stefan Weil wrote:


Hi,

I just wanted to run QEMU CVS with EFI BIOS:

i386-softmmu/qemu -snapshot -L efi-bios -hda efi-bios/efi.disk
linux.img  -net nic,model=i82551 -net user

i82551 is part of the E100 emulator (eepro100.c).

It does not work - no output on serial console nor VGA screen.
Or do I have to press some magic keys to get any response?


EFI Bios worked once with Qemu (around Feb 2007), so certainly  
something was broken.


Happy debugging ;-)

[Qemu-devel] PATCH: block-vvfat.c: fix number_of_entries for filename of length [13]

[Tristan Gingold]

Hi,

when the length of a LFN is a multiple of 13 (ie 26 bytes), no  
padding (0x or 0x) is added.


[ Linux vfat fs follows this policy: in namei.c:xlat_to_uni
*longlen = *outlen;
if (*outlen % 13) {
*op++ = 0;
*op++ = 0;
*outlen += 1;
if (*outlen % 13) {
fill = 13 - (*outlen % 13);
for (i = 0; i  fill; i++) {
*op++ = 0xff;
*op++ = 0xff;
}
*outlen += fill;
}
}
]

This patch fixes this issue.

Tristan.




qemu.diff
Description: Binary data

[Qemu-devel] patch: block-vvfat.c add no-mbr: option

[Tristan Gingold]

Hi,

this very simple patch allows to suppress the (virtual) mbr of block- 
vvfat.  Without an mbr, the fat filesystem

starts obviously at block 0.  Some simple OS doesn't support mbr.

Tristan.


qemu.diff
Description: Binary data

[Qemu-devel] patch: ppc_prep.c: use qemu_alloc_ram

[Tristan Gingold]

Hi,

this patch updates ppc_prep.c.  It now uses qemu_ram_alloc.
The original purpose of this patch was being able to use a bios  
bigger than 1MB.  And updating ppc_prep.c

was a better way than increasing BIOS_SIZE.

Tristan.


qemu.diff
Description: Binary data

Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE

[Tristan Gingold]

Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.72
diff -u -r1.72 ide.c
--- hw/ide.c18 Nov 2007 01:44:37 -  1.72
+++ hw/ide.c30 Nov 2007 14:02:33 -
@@ -2042,6 +2053,7 @@
 ide_set_signature(s);
 s-status = 0x00; /* NOTE: READY is _not_ set */
 s-error = 0x01;
+ide_set_irq(s);
 break;
 case WIN_SRST:
 if (!s-is_cdrom)



is there a way to reproduce that timeout on the guest OS you are  
using?


I confirm this fixes the timeout issue.
Tristan.

Re: [Qemu-devel] EFI BIOS on QEMU

[Tristan Gingold]

On Dec 6, 2007, at 5:58 AM, Kuniyasu Suzaki wrote:



Hello,

We tried EFI BIOS on QEMU.
  http://bellard.org/qemu/efi-bios.tar.bz2

It' fine but the network is not effective. The devices command of  
EFI

does not find a NIC.
# Linux can not set up also network.

Please tell me how to solve this problem. I will re-compile EFI  
BIOS if necessary.


IIRC, tiano only support eepro100.  But I have never tested it.

Tristan.

Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE

[Tristan Gingold]

On Nov 30, 2007, at 3:12 PM, Carlo Marcelo Arenas Belon wrote:
right my bad, missed that on my copy of ATA-4 while looking for a  
match to
your description of the mis-implementation, but why are you  
asserting one

also for the reset?


My fault.  I tried to make code common too quickly!

If I am reading the spec and the code right, the patch should be  
instead :


Looks ok to me.


what is the use case you are trying to solve? which guest OS?


The OS timeout during diagnostic.


is there a way to reproduce that timeout on the guest OS you are  
using?


Sure.  I will try asap.

Tristan.

[Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE

[Tristan Gingold]

Hi,

according to ATA std:
  The pending interrupt condition shall be set by:
  − the completion of a command; or

This patch sends an irq for WIN_DIAGNOSE (and WIN_SRST)

Tristan.




qemu.diff
Description: Binary data

Re: [Qemu-devel] PATCH: ide.c: send irq for WIN_DIAGNOSE

[Tristan Gingold]

On Nov 29, 2007, at 4:07 PM, Carlo Marcelo Arenas Belon wrote:


On Thu, Nov 29, 2007 at 02:05:36PM +0100, Tristan Gingold wrote:

according to ATA std:


which ATA std?


A rather old one: ATA-3


  The pending interrupt condition shall be set by:
  ??? the completion of a command; or

This patch sends an irq for WIN_DIAGNOSE (and WIN_SRST)


DEVICE RESET or DEVICE DIAGNOSTIC in T13/1153D revision 18 don't  
ask for an

irq.


Well, not just after the command is executed.  But according to 9.5.1  
of 1153D:


l) After completing the above steps, Device 0 shall assert INTRQ if  
nIEN is cleared to zero.


So the IRQ is asserted at the end of diagnostic.


what is the use case you are trying to solve? which guest OS?


The OS timeout during diagnostic.

Tristan.

Re: [Qemu-devel] PATCH: fix Makefile issue with make 3.79

[Tristan Gingold]

On Nov 28, 2007, at 11:24 AM, Mike Frysinger wrote:


On Monday 26 November 2007, Tristan Gingold wrote:

$^ is all dependencies (ie the .c and .h files in dyngen case).
Because there is only one .c file to compile, this patch will work in
all cases.


why not simply upgrade your make to something that is not known to  
be broken
and something that isnt ~7 years old.  make-3.80 was released over  
5 years

ago.


Sure, but the proposed patch is not that ugly !

[Qemu-devel] PATCH: fix Makefile issue with make 3.79

[Tristan Gingold]

$^ is all dependencies (ie the .c and .h files in dyngen case).
Because there is only one .c file to compile, this patch will work in  
all cases.


Tristan.


diff -c -r1.136 Makefile
*** Makefile24 Nov 2007 23:35:07 -  1.136
--- Makefile26 Nov 2007 13:17:41 -
***
*** 132,138 

  # dyngen host tool
  dyngen$(EXESUF): dyngen.c
!   $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^

  clean:
  # avoid old build problems by removing potentially incorrect old  
files

--- 132,138 

  # dyngen host tool
  dyngen$(EXESUF): dyngen.c
!   $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $

  clean:
  # avoid old build problems by removing potentially incorrect old  
files

[Qemu-devel] PATCH: add input buffer to mux chr

[Tristan Gingold]

Hi,

when the -nographic switch is set, the input can be blocked if the OS  
doesn't read bytes.  This can be
boring especially when the OS is frozen and you'd like to quit qemu  
or inspect registers.


I propose a solution for this issue: add input buffers to the mux  
chr.  Characters are accepted as long as

the buffer is not full, but escape to monitor is always allowed.

Tested for ppc-softmmu, compiled on all targets but cris.

Tristan.


qemu.diff
Description: Binary data

Re: [Qemu-devel] Removal of some target CPU macros

[Tristan Gingold]

Two side comments:


Note that most (all ?) embedded Freescale PowerPC microcontrollers
implement those extensions and that some ones are greatly interrested
with having an usable emulation avaible for those CPUs.


Has anyone started to implement spe ?


- someone provide an open-source hypervisor, compatible with the ones
used on real machines, that would allow at least Linux to be able  
to run

on a CPU with hypervisor mode available.


Does xen/ppc satisfy your requirement ?
Maybe Hollis will comment.

[Qemu-devel] fake device to access to host fs

[Tristan Gingold]

Hi,

has anyone already implemented a fake device to access to the host FS ?

I am planning to implement one soon, but if it is already available...

Thanks,
Tristan.

Re: [Qemu-devel] fake device to access to host fs

[Tristan Gingold]

On Nov 8, 2007, at 5:35 PM, Eduardo Felipe wrote:


Have a look to the vvfat  block device.


Thanks, I was not aware of it.  I think it will fill my requirements.

[Qemu-devel] Ping: PATCH: fix configure for cygwin

[Tristan Gingold]

Hi,

any comment/review on this patch ?

Is there any interest for Win32 ?  I have patches (serial input from  
console) to port to the current version.


TIA,
Tristan.

On Jul 3, 2007, at 3:03 PM, Tristan Gingold wrote:

this patch fixes two minors issue for cygwin:
* --disable-kqemu didn't work for this configuration (because  
overridden)

* -mno-cygwin was missing in the final link.

Tristan.
qemu-mingw.diff

[Qemu-devel] PATCH: fix configure for cygwin

[Tristan Gingold]

Hi,


this patch fixes two minors issue for cygwin:
* --disable-kqemu didn't work for this configuration (because  
overridden)

* -mno-cygwin was missing in the final link.

Tristan.


qemu-mingw.diff
Description: Binary data

[Qemu-devel] PATCH: serial.c

[Tristan Gingold]

Hi,

According to the documentation, reading IIR does not reset any  
pending interrupt.

This issue caused VxWorks to freeze.

Tristan.

*** hw/serial.c 31 Mar 2007 16:54:14 -  1.15
--- hw/serial.c 4 May 2007 12:49:34 -
***
*** 233,242 
  break;
  case 2:
  ret = s-iir;
- /* reset THR pending bit */
- if ((ret  0x7) == UART_IIR_THRI)
- s-thr_ipending = 0;
- serial_update_irq(s);
  break;
  case 3:
  ret = s-lcr;
--- 233,238 

Re: [Qemu-devel] PATCH: serial.c

[Tristan Gingold]

On May 4, 2007, at 3:34 PM, Wessel, Jason wrote:


Tristan,

I do not believe that is actually the problem, and arguably QEMU is
correct with timing accuracy set aside.  The root of the issue is a  
more
of a timing problem because the clear/set can happen atomically in  
QEMU
with respect to the cpu clock vs the real hardware which takes  
multiple

clock cycles for this to happen.  Even Linux can fall victim to this
with heavy printk (if you have ever seen the message too much work  
for

interrupt).
I think this is a different issue: QEMU serial baudrate is almost  
infinite and linux interrupt

handler detects IRQ storm IIRC.

You should instead consider fixing the BSP i8250Sio.c, because it  
clears

reads the iir and jumps out of the main serial loop if there is if it
has done enough work, vs checking if it has done enough work and  
jumping

out of the loop before reading the iir.

I don't agree because IIR is not cleared when read.
Yes the handler first reads IIR and then jump out of the loop if it  
has done enough work but
the interrupt is not cleared (because the xmit register is still  
empty) and cpu should enter into the interrupt

function as soon as the interrupts are still enabled.

IMHO changing the code (ie inverting the tests) is a (valuable) work- 
around.


Tristan.