Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
NB: Addition of these builtins was prompted by qemu failing to build on armel in Ubuntu; this is because we default to Thumb 2 mode which doesn't have the assembly instructions in question. http://launchpadlibrarian.net/38837077/buildlog_ubuntu-lucid-armel.qemu-kvm_0.12.2-0ubuntu6_FAILEDTOBUILD.txt.gz [...] CCarm-softmmu/syborg_virtio.o CCarm-softmmu/exec.o /tmp/cc24C9yx.s: Assembler messages: /tmp/cc24C9yx.s:5392: Error: selected processor does not support `swp r4,r4,[r3]' /tmp/cc24C9yx.s:6599: Error: selected processor does not support `swp r6,r6,[r3]' make[2]: *** [exec.o] Error 1 make[1]: *** [subdir-arm-softmmu] Error 2 [...] On Sat, Feb 20, 2010, malc wrote: > Please look up "gcc 4.1 implements compiler builtins for atomic ops" > thread for reasons why this might not be the best idea. I found a very old thred (2005) on libc-alpha with this subject; is this the one you mean? People participating in the libc-alpha were not really constructive and were presenting some bogus arguments; let me try to go over the various arguments (long): - some people wanted atomic builtins to be inline for performance and others wanted them to be library calls to allow changing their behavior later (e.g. to support a new CPU); the implementation actually uses both: inline assembly when supported on the architecture, or calls into libgcc which will call into the kernel otherwise (or direct calls into the kernel when building statically obviously), such as when the ISA doesn't offer sufficient primitives. Because *any* instruction might be gotten wrong in hardware, I don't see a need to special case locking inline assembly. - userspace apps abusing atomic builtins for locking; this is actually the case of qemu, but I think using gcc primitives will actually make it easier to get it right and will allow coverage of more architectures; in my opinion, there's no need to maintain hand-written assembly for locks in 2010. - someone claimed that modern architectures can do these operations in assembly without calling into a library; that's what the atomic builtins do, and actually some modern architectures can't do all operations in assembly. - there were arguments over where such functions belong and the semantics of each call; these are in my eyes purely political and don't relate to qemu. Which are your concerns with atomic builtins and are these in the above list? -- Loïc Minier
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
On Sat, 20 Feb 2010, Lo?c Minier wrote: > NB: Addition of these builtins was prompted by qemu failing to build on > armel in Ubuntu; this is because we default to Thumb 2 mode which > doesn't have the assembly instructions in question. > > http://launchpadlibrarian.net/38837077/buildlog_ubuntu-lucid-armel.qemu-kvm_0.12.2-0ubuntu6_FAILEDTOBUILD.txt.gz > [...] > CCarm-softmmu/syborg_virtio.o > CCarm-softmmu/exec.o > /tmp/cc24C9yx.s: Assembler messages: > /tmp/cc24C9yx.s:5392: Error: selected processor does not support `swp > r4,r4,[r3]' > /tmp/cc24C9yx.s:6599: Error: selected processor does not support `swp > r6,r6,[r3]' > make[2]: *** [exec.o] Error 1 > make[1]: *** [subdir-arm-softmmu] Error 2 > [...] > > On Sat, Feb 20, 2010, malc wrote: > > Please look up "gcc 4.1 implements compiler builtins for atomic ops" > > thread for reasons why this might not be the best idea. > > I found a very old thred (2005) on libc-alpha with this subject; is > this the one you mean? Yes. > > People participating in the libc-alpha were not really constructive and > were presenting some bogus arguments; let me try to go over the various > arguments (long): > - some people wanted atomic builtins to be inline for performance and >others wanted them to be library calls to allow changing their >behavior later (e.g. to support a new CPU); the implementation >actually uses both: inline assembly when supported on the >architecture, or calls into libgcc which will call into the kernel >otherwise (or direct calls into the kernel when building statically >obviously), such as when the ISA doesn't offer sufficient primitives. >Because *any* instruction might be gotten wrong in hardware, I don't >see a need to special case locking inline assembly. > - userspace apps abusing atomic builtins for locking; this is actually >the case of qemu, but I think using gcc primitives will actually make >it easier to get it right and will allow coverage of more >architectures; in my opinion, there's no need to maintain >hand-written assembly for locks in 2010. > - someone claimed that modern architectures can do these operations in >assembly without calling into a library; that's what the atomic >builtins do, and actually some modern architectures can't do all >operations in assembly. > - there were arguments over where such functions belong and the >semantics of each call; these are in my eyes purely political and >don't relate to qemu. > > Which are your concerns with atomic builtins and are these in the above > list? For instance this: http://sources.redhat.com/ml/libc-alpha/2005-06/msg00112.html The builtins are too coarse grained and will do more stuff than strictly necessary. -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
when exiting qemu that run with "-monitor /dev/tty", the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivi
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd, &tty);
+oldtty = tty;
#define check_speed(val) if (speed <= val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr, int
cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW, &oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, "path");
@@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
return NULL;
}
chr->chr_ioctl = tty_serial_ioctl;
+chr->chr_close = qemu_chr_close_tty;
+atexit(tty_exit);
return chr;
}
#else /* ! __linux__ && ! __sun__ */
--
1.6.3.3
Re: [Qemu-devel] [PATCH] target-sparc: fix --enable-debug build
On 2/19/10, Jay Foad wrote: > On Linux/x86, configuring with --enable-debug, I get: > > CCsparc64-linux-user/translate.o > /home/foad/git/qemu/target-sparc/translate.c: In function > ‘gen_load_trap_state_at_tl’: > /home/foad/git/qemu/target-sparc/translate.c:1684: error: incompatible > type for argument 3 of ‘tcg_gen_add_i32’ > /home/foad/git/qemu/tcg/tcg-op.h:422: note: expected ‘TCGv_i32’ but > argument is of type ‘TCGv_i64’ > make[1]: *** [translate.o] Error 1 > > Does this look like a reasonable fix? > > Signed-off-by: Jay Foad Yes, except for the Signed-off-by: line.
Re: [Qemu-devel] [PATCH] tcg: fix assertion with --enable-debug
On 2/19/10, Jay Foad wrote: > After configuring with --enable-debug on Linux/x86, I get: > > f...@foad-ubuntu:~/qemu/objdir-git$ qemu-alpha /dev/null > qemu-alpha: /home/foad/git/qemu/tcg/tcg.c:1055: > tcg_add_target_add_op_defs: Assertion `tcg_op_defs[op].used' failed. > Aborted > > (and the same for all other targets). The qemu_ld32s op appears to be > unused on 32-bit hosts. Is it OK to just remove it? Should be OK.
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
On Sat, Feb 20, 2010, malc wrote: > For instance this: > http://sources.redhat.com/ml/libc-alpha/2005-06/msg00112.html > > The builtins are too coarse grained and will do more stuff than strictly > necessary. Is this the case of the builtins I'm proposing to use? We could ask for new ones without the drawbacks if any. Do you have another option to implement locking on thumb-2? -- Loïc Minier
[Qemu-devel] Re: [PATCH 0/7] tcg-sparc improvements, v2
Thanks, applied all. On 2/19/10, Richard Henderson wrote: > Changes since v1: > * Add comments for all optional instructions that aren't implemented >on each architecture, as requested. > * Rebase vs master. > > > r~ > > > Richard Henderson (7): > tcg-sparc: Implement neg. > tcg-sparc: Implement not. > tcg: Optional target implementation of ANDC. > tcg: Optional target implementation of ORC. > tcg-sparc: Implement ANDC. > tcg-sparc: Implement ORC. > tcg: Add comments for all optional instructions not implemented. > > tcg/arm/tcg-target.h| 14 ++ > tcg/i386/tcg-target.h | 12 +++- > tcg/mips/tcg-target.h |4 +++- > tcg/ppc/tcg-target.h| 10 +- > tcg/ppc64/tcg-target.h | 25 ++--- > tcg/s390/tcg-target.h | 30 ++ > tcg/sparc/tcg-target.c | 30 ++ > tcg/sparc/tcg-target.h | 31 --- > tcg/tcg-op.h| 22 ++ > tcg/tcg-opc.h | 12 > tcg/x86_64/tcg-target.h |6 +- > 11 files changed, 178 insertions(+), 18 deletions(-) > >
Re: [Qemu-devel] [PATCH] target-sparc: fix --enable-debug build
> Yes, except for the Signed-off-by: line. Do I need to resend it for that? And if so, does that make it PATCH v2 (even though the patch hasn't changed)? Or can I just put the fixed Signed-off-by: line in a reply? Thanks, Jay.
Re: [Qemu-devel] [PATCH] target-sparc: fix --enable-debug build
On 2/20/10, Jay Foad wrote: > > Yes, except for the Signed-off-by: line. > > > Do I need to resend it for that? And if so, does that make it PATCH v2 > (even though the patch hasn't changed)? > > Or can I just put the fixed Signed-off-by: line in a reply? I'd suppose you'd also want to trim the commit message to remove the question, so please send a new patch.
[Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
On 32-bit hosts op_qemu_ld32s is unused. Remove it to fix the following assertion failure: qemu-alpha: tcg/tcg.c:1055: tcg_add_target_add_op_defs: Assertion `tcg_op_defs[op].used' failed. Signed-off-by: Jay Foad --- tcg/tcg-opc.h |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h index 89db3b4..838f1f4 100644 --- a/tcg/tcg-opc.h +++ b/tcg/tcg-opc.h @@ -224,11 +224,6 @@ DEF2(qemu_ld32u, 1, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) DEF2(qemu_ld32u, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) #endif #if TARGET_LONG_BITS == 32 -DEF2(qemu_ld32s, 1, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) -#else -DEF2(qemu_ld32s, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) -#endif -#if TARGET_LONG_BITS == 32 DEF2(qemu_ld64, 2, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) #else DEF2(qemu_ld64, 2, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS)
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
Thanks, applied. On 2/20/10, Jay Foad wrote: > On 32-bit hosts op_qemu_ld32s is unused. Remove it to fix the > following assertion failure: > > qemu-alpha: tcg/tcg.c:1055: > tcg_add_target_add_op_defs: Assertion `tcg_op_defs[op].used' failed. > > Signed-off-by: Jay Foad > --- > tcg/tcg-opc.h |5 - > 1 files changed, 0 insertions(+), 5 deletions(-) > > diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h > index 89db3b4..838f1f4 100644 > --- a/tcg/tcg-opc.h > +++ b/tcg/tcg-opc.h > @@ -224,11 +224,6 @@ DEF2(qemu_ld32u, 1, 1, 1, TCG_OPF_CALL_CLOBBER | > TCG_OPF_SIDE_EFFECTS) > DEF2(qemu_ld32u, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) > #endif > #if TARGET_LONG_BITS == 32 > -DEF2(qemu_ld32s, 1, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) > -#else > -DEF2(qemu_ld32s, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) > -#endif > -#if TARGET_LONG_BITS == 32 > DEF2(qemu_ld64, 2, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) > #else > DEF2(qemu_ld64, 2, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) > > >
[Qemu-devel] [PATCH v2] target-sparc: fix --enable-debug build
Use 32-bit arithmetic for the address offset calculation to fix a
build failure on 32-bit hosts.
Signed-off-by: Jay Foad
---
target-sparc/translate.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 7e9f0cf..b7d2a32 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -1663,27 +1663,27 @@ static inline TCGv get_src2(unsigned int insn, TCGv def)
#ifdef TARGET_SPARC64
static inline void gen_load_trap_state_at_tl(TCGv_ptr r_tsptr,
TCGv_ptr cpu_env)
{
-TCGv r_tl = tcg_temp_new();
+TCGv_i32 r_tl = tcg_temp_new_i32();
/* load env->tl into r_tl */
-{
-TCGv_i32 r_tl_tmp = tcg_temp_new_i32();
-tcg_gen_ld_i32(r_tl_tmp, cpu_env, offsetof(CPUSPARCState, tl));
-tcg_gen_ext_i32_tl(r_tl, r_tl_tmp);
-tcg_temp_free_i32(r_tl_tmp);
-}
+tcg_gen_ld_i32(r_tl, cpu_env, offsetof(CPUSPARCState, tl));
/* tl = [0 ... MAXTL_MASK] where MAXTL_MASK must be power of 2 */
-tcg_gen_andi_tl(r_tl, r_tl, MAXTL_MASK);
+tcg_gen_andi_i32(r_tl, r_tl, MAXTL_MASK);
/* calculate offset to current trap state from env->ts, reuse r_tl */
-tcg_gen_muli_tl(r_tl, r_tl, sizeof (trap_state));
+tcg_gen_muli_i32(r_tl, r_tl, sizeof (trap_state));
tcg_gen_addi_ptr(r_tsptr, cpu_env, offsetof(CPUState, ts));
/* tsptr = env->ts[env->tl & MAXTL_MASK] */
-tcg_gen_add_ptr(r_tsptr, r_tsptr, r_tl);
+{
+TCGv_ptr r_tl_tmp = tcg_temp_new_ptr();
+tcg_gen_ext_i32_ptr(r_tl_tmp, r_tl);
+tcg_gen_add_ptr(r_tsptr, r_tsptr, r_tl_tmp);
+tcg_temp_free_i32(r_tl_tmp);
+}
-tcg_temp_free(r_tl);
+tcg_temp_free_i32(r_tl);
}
#endif
Re: [Qemu-devel] [PATCH v2] target-sparc: fix --enable-debug build
Thanks, applied.
On 2/20/10, Jay Foad wrote:
> Use 32-bit arithmetic for the address offset calculation to fix a
> build failure on 32-bit hosts.
>
> Signed-off-by: Jay Foad
> ---
> target-sparc/translate.c | 22 +++---
> 1 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/target-sparc/translate.c b/target-sparc/translate.c
> index 7e9f0cf..b7d2a32 100644
> --- a/target-sparc/translate.c
> +++ b/target-sparc/translate.c
> @@ -1663,27 +1663,27 @@ static inline TCGv get_src2(unsigned int insn, TCGv
> def)
> #ifdef TARGET_SPARC64
> static inline void gen_load_trap_state_at_tl(TCGv_ptr r_tsptr,
> TCGv_ptr cpu_env)
> {
> -TCGv r_tl = tcg_temp_new();
> +TCGv_i32 r_tl = tcg_temp_new_i32();
>
> /* load env->tl into r_tl */
> -{
> -TCGv_i32 r_tl_tmp = tcg_temp_new_i32();
> -tcg_gen_ld_i32(r_tl_tmp, cpu_env, offsetof(CPUSPARCState, tl));
> -tcg_gen_ext_i32_tl(r_tl, r_tl_tmp);
> -tcg_temp_free_i32(r_tl_tmp);
> -}
> +tcg_gen_ld_i32(r_tl, cpu_env, offsetof(CPUSPARCState, tl));
>
> /* tl = [0 ... MAXTL_MASK] where MAXTL_MASK must be power of 2 */
> -tcg_gen_andi_tl(r_tl, r_tl, MAXTL_MASK);
> +tcg_gen_andi_i32(r_tl, r_tl, MAXTL_MASK);
>
> /* calculate offset to current trap state from env->ts, reuse r_tl */
> -tcg_gen_muli_tl(r_tl, r_tl, sizeof (trap_state));
> +tcg_gen_muli_i32(r_tl, r_tl, sizeof (trap_state));
> tcg_gen_addi_ptr(r_tsptr, cpu_env, offsetof(CPUState, ts));
>
> /* tsptr = env->ts[env->tl & MAXTL_MASK] */
> -tcg_gen_add_ptr(r_tsptr, r_tsptr, r_tl);
> +{
> +TCGv_ptr r_tl_tmp = tcg_temp_new_ptr();
> +tcg_gen_ext_i32_ptr(r_tl_tmp, r_tl);
> +tcg_gen_add_ptr(r_tsptr, r_tsptr, r_tl_tmp);
> +tcg_temp_free_i32(r_tl_tmp);
> +}
>
> -tcg_temp_free(r_tl);
> +tcg_temp_free_i32(r_tl);
> }
> #endif
>
>
>
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 01:30 AM, Shahar Havivi wrote:
> when exiting qemu that run with "-monitor /dev/tty", the launching
> terminal get weird behaviour because no restore terminals action has
> taken.
> added chr_close and register atexit() code for tty devices (like stdio
> does)
>
> Signed-off-by: Shahar Havivi
> ---
> qemu-char.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 75dbf66..de16883 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
> speed, parity, data_bits, stop_bits);
> #endif
> tcgetattr (fd, &tty);
> +oldtty = tty;
>
> #define check_speed(val) if (speed <= val) { spd = B##val; break; }
> speed = speed * 10 / 11;
> @@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr, int
> cmd, void *arg)
> return 0;
> }
>
> +static void tty_exit(void)
> +{
> +tcsetattr(0, TCSANOW, &oldtty);
> +}
> +
> +static void qemu_chr_close_tty(struct CharDriverState *chr)
> +{
> +tty_exit();
> +fd_chr_close(chr);
> +}
The close callback needs to close the fd for the device as well. I have
sent a patch to handle this; waiting for it to be included:
http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
David
> +
> static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
> {
> const char *filename = qemu_opt_get(opts, "path");
> @@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
> *opts)
> return NULL;
> }
> chr->chr_ioctl = tty_serial_ioctl;
> +chr->chr_close = qemu_chr_close_tty;
> +atexit(tty_exit);
> return chr;
> }
> #else /* ! __linux__ && ! __sun__ */
[Qemu-devel] [PATCH] rewrote timer implementation for rtl8139.
Add a QEMU timer only when needed (timeout status not set, timeout
irq wanted and timer set).
This patch is required for Darwin. Patch has been tested under
FreeBSD, Darwin and Linux.
---
hw/rtl8139.c | 139 +++---
1 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index f04dd54..72e2242 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -41,6 +41,10 @@
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling
rx/tx operation
+ *
+ * 2010-Feb-04 Frediano Ziglio: Rewrote timer support using QEMU timer only
+ * when strictly needed (required for for
+ * Darwin)
*/
#include "hw.h"
@@ -60,9 +64,6 @@
/* Calculate CRCs properly on Rx packets */
#define RTL8139_CALCULATE_RXCRC 1
-/* Uncomment to enable on-board timer interrupts */
-//#define RTL8139_ONBOARD_TIMER 1
-
#if defined(RTL8139_CALCULATE_RXCRC)
/* For crc32 */
#include
@@ -491,9 +492,12 @@ typedef struct RTL8139State {
/* PCI interrupt timer */
QEMUTimer *timer;
+int64_t TimerExpire;
} RTL8139State;
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time);
+
static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
{
DEBUG_PRINT(("RTL8139: eeprom command 0x%02x\n", command));
@@ -2522,7 +2526,9 @@ static void rtl8139_IntrMask_write(RTL8139State *s,
uint32_t val)
s->IntrMask = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
}
static uint32_t rtl8139_IntrMask_read(RTL8139State *s)
@@ -2555,12 +2561,22 @@ static void rtl8139_IntrStatus_write(RTL8139State *s,
uint32_t val)
rtl8139_update_irq(s);
s->IntrStatus = newStatus;
+/*
+ * Computing if we miss an interrupt here is not that correct but
+ * considered that we should have had already an interrupt
+ * and probably emulated is slower is better to assume this resetting was
+ * done before testing on previous rtl8139_update_irq lead to IRQ loosing
+ */
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
#endif
}
static uint32_t rtl8139_IntrStatus_read(RTL8139State *s)
{
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
uint32_t ret = s->IntrStatus;
DEBUG_PRINT(("RTL8139: IntrStatus read(w) val=0x%04x\n", ret));
@@ -2739,6 +2755,46 @@ static void rtl8139_io_writew(void *opaque, uint8_t
addr, uint32_t val)
}
}
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time)
+{
+int64_t pci_time, next_time;
+uint32_t low_pci;
+
+DEBUG_PRINT(("RTL8139: entered rtl8139_set_next_tctr_time\n"));
+
+if (s->TimerExpire && current_time >= s->TimerExpire) {
+s->IntrStatus |= PCSTimeout;
+rtl8139_update_irq(s);
+}
+
+/* Set QEMU timer only if needed that is
+ * - TimerInt <> 0 (we have a timer)
+ * - mask = 1 (we want an interrupt timer)
+ * - irq = 0 (irq is not already active)
+ * If any of above change we need to compute timer again
+ * Also we must check if timer is passed without QEMU timer
+ */
+s->TimerExpire = 0;
+if (!s->TimerInt) {
+return;
+}
+
+pci_time = muldiv64(current_time - s->TCTR_base, PCI_FREQUENCY,
+get_ticks_per_sec());
+low_pci = pci_time & 0x;
+pci_time = pci_time - low_pci + s->TimerInt;
+if (low_pci >= s->TimerInt) {
+pci_time += 0x1LL;
+}
+next_time = s->TCTR_base + muldiv64(pci_time, get_ticks_per_sec(),
+PCI_FREQUENCY);
+s->TimerExpire = next_time;
+
+if ((s->IntrMask & PCSTimeout) != 0 && (s->IntrStatus & PCSTimeout) == 0) {
+qemu_mod_timer(s->timer, next_time);
+}
+}
+
static void rtl8139_io_writel(void *opaque, uint8_t addr, uint32_t val)
{
RTL8139State *s = opaque;
@@ -2784,13 +2840,16 @@ static void rtl8139_io_writel(void *opaque, uint8_t
addr, uint32_t val)
case Timer:
DEBUG_PRINT(("RTL8139: TCTR Timer reset on write\n"));
-s->TCTR = 0;
s->TCTR_base = qemu_get_clock(vm_clock);
+rtl8139_set_next_tctr_time(s, s->TCTR_base);
break;
case FlashReg:
DEBUG_PRINT(("RTL8139: FlashReg TimerInt write val=0x%08x\n",
val));
-s->TimerInt = val;
+if (s->TimerInt != val) {
+s->TimerInt = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+}
break;
default:
@@ -3000,7 +3059,8 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t
addr)
break;
case Timer:
-re
Re: [Qemu-devel] [PATCH] rewrote timer implementation for rtl8139.
2010/2/20 Igor Kovalenko : > On Sat, Feb 20, 2010 at 2:26 AM, Anthony Liguori > wrote: >> On 02/19/2010 04:22 PM, Alexander Graf wrote: >>> >>> On 19.02.2010, at 22:50, Anthony Liguori wrote: >>> >>> On 02/16/2010 02:35 AM, Frediano Ziglio wrote: > > Add a QEMU timer only when needed (timeout status not set, timeout > irq wanted and timer set). > > This patch is required for Darwin. Patch has been tested under > FreeBSD, Darwin and Linux. > > Signed-off-by: Frediano Ziglio > > Alex, I know you've played with this feature for OS X in the past. Is this something we should be enabling unconditionally? >>> >>> I've played with it and realized that >>> >>> 1) OSX's rtl8139 driver uses this timer instead of tx/rx interrupts to >>> process the queue >>> 2) it was broken >>> >>> I haven't gotten around to test if this patch makes it work, but I'd >>> suppose so. >>> >>> So yes, I think it should be enabled by default. It's a feature real hw >>> has, so we should emulate it. >>> >> >> The thing that concerns me is why it was disabled by default. Igor, what >> was the reasoning for disabling it if you recall? > > It was very inefficient pci timer implementation which fired callback > frequently. > Once it was found that (freebsd?) was relying on pci timer in realtek driver > to communicate we just added missing piece. > > Now this patch fixes that inefficiency issue. > I'm not that use with this ML way... sorry if somebody will receive a lot of SPAM... I updated my patch with Anthony suggestions (just code style). Previous code (current git) issue a timer every pci tick (about 33 millions per second!) in order to compute correctly TCTR. This patch enable QEMU timers only when strictly needed (for interrupt purposes) computing TCTR when needed (only on driver read). I tested with patch under Linux, FreeBSD and Darwin (Mac OS X) and it works correctly. I also bought a physical card to test the behaviour with a small test program and test program work with emulated code too (previously code does not). I sent the test program but I don't know if is possible to integrate it into QEMU code (is a standalone test). Frediano Ziglio
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On Sat, Feb 20, 2010 at 08:18:54AM -0700, David S. Ahern wrote:
> Date: Sat, 20 Feb 2010 08:18:54 -0700
> From: "David S. Ahern"
> To: Shahar Havivi
> CC: qemu-devel@nongnu.org, Dor Laor
> Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
> using /dev/tty monitor
>
>
> On 02/20/2010 01:30 AM, Shahar Havivi wrote:
> > when exiting qemu that run with "-monitor /dev/tty", the launching
> > terminal get weird behaviour because no restore terminals action has
> > taken.
> > added chr_close and register atexit() code for tty devices (like stdio
> > does)
> >
> > Signed-off-by: Shahar Havivi
> > ---
> > qemu-char.c | 14 ++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/qemu-char.c b/qemu-char.c
> > index 75dbf66..de16883 100644
> > --- a/qemu-char.c
> > +++ b/qemu-char.c
> > @@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
> > speed, parity, data_bits, stop_bits);
> > #endif
> > tcgetattr (fd, &tty);
> > +oldtty = tty;
> >
> > #define check_speed(val) if (speed <= val) { spd = B##val; break; }
> > speed = speed * 10 / 11;
> > @@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr,
> > int cmd, void *arg)
> > return 0;
> > }
> >
> > +static void tty_exit(void)
> > +{
> > +tcsetattr(0, TCSANOW, &oldtty);
> > +}
> > +
> > +static void qemu_chr_close_tty(struct CharDriverState *chr)
> > +{
> > +tty_exit();
> > +fd_chr_close(chr);
> > +}
>
>
> The close callback needs to close the fd for the device as well. I have
> sent a patch to handle this; waiting for it to be included:
>
> http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
>
> David
Sure you right about the fd but the chr->chr_close not called all the
time that is why I added the atexit() call, and the restore tty flags.
Shaahr.
>
>
> > +
> > static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
> > {
> > const char *filename = qemu_opt_get(opts, "path");
> > @@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
> > *opts)
> > return NULL;
> > }
> > chr->chr_ioctl = tty_serial_ioctl;
> > +chr->chr_close = qemu_chr_close_tty;
> > +atexit(tty_exit);
> > return chr;
> > }
> > #else /* ! __linux__ && ! __sun__ */
Re: [Qemu-devel] Re: [PATCH 0/3] qcow2: Rewrite alloc_refcount_block
On 02/19/2010 07:49 PM, Juan Quintela wrote: Anthony Liguori wrote: On 02/15/2010 10:19 AM, Kevin Wolf wrote: The current implementation of alloc_refcount_block and grow_refcount_table has fundamental problems regarding error handling. There are some places where an I/O error means that the image is going to be corrupted. I have found that the only way to fix this is to completely rewrite the thing. Just sending as an RFC to the list hasn't generated a lot of comments (to be precise, not a single one). This is a critical part of qcow2 and needs reviews. So let's try it another way: People in CC, please give it a review. Sooner or later some of you will need to do so anyway. Should I apply this series? I still don't see any review comments. I sent review comments on the 18th. I expect Kevin to address them. I talked with him on irc while doing the review (i.e. he knows about them). You're right, I missed it. Thanks. Regards, Anthony Liguori Kevin??? Later, Juan.
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 09:18 AM, David S. Ahern wrote:
On 02/20/2010 01:30 AM, Shahar Havivi wrote:
when exiting qemu that run with "-monitor /dev/tty", the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivi
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd,&tty);
+oldtty = tty;
#define check_speed(val) if (speed<= val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr, int
cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW,&oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
The close callback needs to close the fd for the device as well. I have
sent a patch to handle this; waiting for it to be included:
http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
It didn't apply with git-am. I'm not sure why, am investigating now.
Regards,
Anthony Liguori
David
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, "path");
@@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
return NULL;
}
chr->chr_ioctl = tty_serial_ioctl;
+chr->chr_close = qemu_chr_close_tty;
+atexit(tty_exit);
return chr;
}
#else /* ! __linux__&& ! __sun__ */
Re: [Qemu-devel] [PATCH] rewrote timer implementation for rtl8139.
On 02/20/2010 10:06 AM, Frediano Ziglio wrote:
Add a QEMU timer only when needed (timeout status not set, timeout
irq wanted and timer set).
This patch is required for Darwin. Patch has been tested under
FreeBSD, Darwin and Linux.
This is missing a Signed-off-by.
Regards,
Anthony Liguori
---
hw/rtl8139.c | 139 +++---
1 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index f04dd54..72e2242 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -41,6 +41,10 @@
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling
rx/tx operation
+ *
+ * 2010-Feb-04 Frediano Ziglio: Rewrote timer support using QEMU timer only
+ * when strictly needed (required for for
+ * Darwin)
*/
#include "hw.h"
@@ -60,9 +64,6 @@
/* Calculate CRCs properly on Rx packets */
#define RTL8139_CALCULATE_RXCRC 1
-/* Uncomment to enable on-board timer interrupts */
-//#define RTL8139_ONBOARD_TIMER 1
-
#if defined(RTL8139_CALCULATE_RXCRC)
/* For crc32 */
#include
@@ -491,9 +492,12 @@ typedef struct RTL8139State {
/* PCI interrupt timer */
QEMUTimer *timer;
+int64_t TimerExpire;
} RTL8139State;
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time);
+
static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
{
DEBUG_PRINT(("RTL8139: eeprom command 0x%02x\n", command));
@@ -2522,7 +2526,9 @@ static void rtl8139_IntrMask_write(RTL8139State *s,
uint32_t val)
s->IntrMask = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
}
static uint32_t rtl8139_IntrMask_read(RTL8139State *s)
@@ -2555,12 +2561,22 @@ static void rtl8139_IntrStatus_write(RTL8139State *s,
uint32_t val)
rtl8139_update_irq(s);
s->IntrStatus = newStatus;
+/*
+ * Computing if we miss an interrupt here is not that correct but
+ * considered that we should have had already an interrupt
+ * and probably emulated is slower is better to assume this resetting was
+ * done before testing on previous rtl8139_update_irq lead to IRQ loosing
+ */
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
#endif
}
static uint32_t rtl8139_IntrStatus_read(RTL8139State *s)
{
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
uint32_t ret = s->IntrStatus;
DEBUG_PRINT(("RTL8139: IntrStatus read(w) val=0x%04x\n", ret));
@@ -2739,6 +2755,46 @@ static void rtl8139_io_writew(void *opaque, uint8_t
addr, uint32_t val)
}
}
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time)
+{
+int64_t pci_time, next_time;
+uint32_t low_pci;
+
+DEBUG_PRINT(("RTL8139: entered rtl8139_set_next_tctr_time\n"));
+
+if (s->TimerExpire&& current_time>= s->TimerExpire) {
+s->IntrStatus |= PCSTimeout;
+rtl8139_update_irq(s);
+}
+
+/* Set QEMU timer only if needed that is
+ * - TimerInt<> 0 (we have a timer)
+ * - mask = 1 (we want an interrupt timer)
+ * - irq = 0 (irq is not already active)
+ * If any of above change we need to compute timer again
+ * Also we must check if timer is passed without QEMU timer
+ */
+s->TimerExpire = 0;
+if (!s->TimerInt) {
+return;
+}
+
+pci_time = muldiv64(current_time - s->TCTR_base, PCI_FREQUENCY,
+get_ticks_per_sec());
+low_pci = pci_time& 0x;
+pci_time = pci_time - low_pci + s->TimerInt;
+if (low_pci>= s->TimerInt) {
+pci_time += 0x1LL;
+}
+next_time = s->TCTR_base + muldiv64(pci_time, get_ticks_per_sec(),
+PCI_FREQUENCY);
+s->TimerExpire = next_time;
+
+if ((s->IntrMask& PCSTimeout) != 0&& (s->IntrStatus& PCSTimeout) == 0) {
+qemu_mod_timer(s->timer, next_time);
+}
+}
+
static void rtl8139_io_writel(void *opaque, uint8_t addr, uint32_t val)
{
RTL8139State *s = opaque;
@@ -2784,13 +2840,16 @@ static void rtl8139_io_writel(void *opaque, uint8_t
addr, uint32_t val)
case Timer:
DEBUG_PRINT(("RTL8139: TCTR Timer reset on write\n"));
-s->TCTR = 0;
s->TCTR_base = qemu_get_clock(vm_clock);
+rtl8139_set_next_tctr_time(s, s->TCTR_base);
break;
case FlashReg:
DEBUG_PRINT(("RTL8139: FlashReg TimerInt write val=0x%08x\n",
val));
-s->TimerInt = val;
+if (s->TimerInt != val) {
+s->TimerInt = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+}
break;
default:
[Qemu-devel] Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: > 2010/2/17 Rob Landley : > > But it does imply that qemu is capable of decently running _something_ on > > sparc, so the problems I'm seeing are more likely to be uClibc or > > toolchain issues. > > qemu-sparc can decently run debian-40r8: gcc and all the other stuff > seem to work. > > Most versions of the NetBSD boot. Some require the original OBP > though. The only known to me version which definetely doesn't boot is > 3.0.2. > > Also since the last dma fix Solaris 2.4-2.5.1 seems to be also fully > functional. Don't have a suitable compiler to check whether it's > working under Solaris though. > > Debian-40r8 should have all the necessary stuff to build the uClibc > toolchain, right? So I did a network install of that Debian image into a 4 gig disk image, and made some progress. First a quick bug report: qemu-system-sparc tries to set the video window to 900 pixels vertical, but my laptop's display is only 800 pixels tall, and the window manager trims it a bit more than that for the toolbar. The kernel booting up seems to think the graphics window is still its original size renders text off the bottom of it. But for some reason I can grab the window and resize it, and when I do this the emulated kernel's frame buffer gets the update and resizes its console to show the correct number of lines of text for the new size! (So my question is, why didn't it get the size right when the window manager first resized it before I manually resized it again?) Anyway: yay emulated sparc debian, I installed it, got a reasonable environment going, extracted my root filesystem image under there and chrooted into it... and everything worked fine. (Well, trying to run a dynamically linked "hello world" still died with a bus error, but using the static busybox I could mount a tmpfs and list its contents, which I never could before.) My plan had been to use sparc-debian's copy of gdb to track down why the binaries were going funky... but in that environment, they were behaving themselves. Same binaries, built with the same toolchain, same qemu-system- sparc, same -M and -cpu and so on... So I think "A-ha! Booting a different kernel! That's gotta be it!" The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.32 kernel), but it installed the relevant .config in /boot, so I copied that out with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter key until it shut up), stripped out all the modules and disabled module support, put back in CONFIG_SERIAL_SUNZILOG_CONSOLE=y and friends, procfs, sysfs, and tmpfs (strange things to have as modules?), and CONFIG_SQUASHFS (that's my default root filesystem format). I booted the result up with init=/bin/ash, did a "mount -t tmpfs /tmp /tmp", and then: / # ls -l /tmp Illegal instruction It's still misbehaving. Huh. This is as close as I can get to the debian kernel config without adding module support to my images (which is unnecessary complication for what they do). I can try an ext2 root filesystem image but I don't see how that would cause this. The part I don't understand is that same busybox binary, built with the same toolchain, worked just fine under the Debian kernel. I'd blame my toolchain, but in a slightly different context THE BINARIES WORKED... I don't understand what's going wrong here. Did the kernel break on sparc sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc using software emulated floating point at the kernel level and that's configured as a module? (Except I don't think busybox ls uses floating point...) Do any sparc people understand what's going on here? My next step is to grab a 2.6.18 kernel and try to get _that_ to work with the tweaked debian config (and an ext2 root filesystem since squashfs wasn't merged back then and had a format change when it was merged). But I'm mostly flailing around blind here... Thanks, Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
[Qemu-devel] [PATCH] rewrote timer implementation for rtl8139.
Add a QEMU timer only when needed (timeout status not set, timeout
irq wanted and timer set).
This patch is required for Darwin. Patch has been tested under
FreeBSD, Darwin and Linux.
---
hw/rtl8139.c | 139 +++---
1 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index f04dd54..72e2242 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -41,6 +41,10 @@
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling
rx/tx operation
+ *
+ * 2010-Feb-04 Frediano Ziglio: Rewrote timer support using QEMU timer only
+ * when strictly needed (required for for
+ * Darwin)
*/
#include "hw.h"
@@ -60,9 +64,6 @@
/* Calculate CRCs properly on Rx packets */
#define RTL8139_CALCULATE_RXCRC 1
-/* Uncomment to enable on-board timer interrupts */
-//#define RTL8139_ONBOARD_TIMER 1
-
#if defined(RTL8139_CALCULATE_RXCRC)
/* For crc32 */
#include
@@ -491,9 +492,12 @@ typedef struct RTL8139State {
/* PCI interrupt timer */
QEMUTimer *timer;
+int64_t TimerExpire;
} RTL8139State;
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time);
+
static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
{
DEBUG_PRINT(("RTL8139: eeprom command 0x%02x\n", command));
@@ -2522,7 +2526,9 @@ static void rtl8139_IntrMask_write(RTL8139State *s,
uint32_t val)
s->IntrMask = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
}
static uint32_t rtl8139_IntrMask_read(RTL8139State *s)
@@ -2555,12 +2561,22 @@ static void rtl8139_IntrStatus_write(RTL8139State *s,
uint32_t val)
rtl8139_update_irq(s);
s->IntrStatus = newStatus;
+/*
+ * Computing if we miss an interrupt here is not that correct but
+ * considered that we should have had already an interrupt
+ * and probably emulated is slower is better to assume this resetting was
+ * done before testing on previous rtl8139_update_irq lead to IRQ loosing
+ */
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
#endif
}
static uint32_t rtl8139_IntrStatus_read(RTL8139State *s)
{
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
uint32_t ret = s->IntrStatus;
DEBUG_PRINT(("RTL8139: IntrStatus read(w) val=0x%04x\n", ret));
@@ -2739,6 +2755,46 @@ static void rtl8139_io_writew(void *opaque, uint8_t
addr, uint32_t val)
}
}
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time)
+{
+int64_t pci_time, next_time;
+uint32_t low_pci;
+
+DEBUG_PRINT(("RTL8139: entered rtl8139_set_next_tctr_time\n"));
+
+if (s->TimerExpire && current_time >= s->TimerExpire) {
+s->IntrStatus |= PCSTimeout;
+rtl8139_update_irq(s);
+}
+
+/* Set QEMU timer only if needed that is
+ * - TimerInt <> 0 (we have a timer)
+ * - mask = 1 (we want an interrupt timer)
+ * - irq = 0 (irq is not already active)
+ * If any of above change we need to compute timer again
+ * Also we must check if timer is passed without QEMU timer
+ */
+s->TimerExpire = 0;
+if (!s->TimerInt) {
+return;
+}
+
+pci_time = muldiv64(current_time - s->TCTR_base, PCI_FREQUENCY,
+get_ticks_per_sec());
+low_pci = pci_time & 0x;
+pci_time = pci_time - low_pci + s->TimerInt;
+if (low_pci >= s->TimerInt) {
+pci_time += 0x1LL;
+}
+next_time = s->TCTR_base + muldiv64(pci_time, get_ticks_per_sec(),
+PCI_FREQUENCY);
+s->TimerExpire = next_time;
+
+if ((s->IntrMask & PCSTimeout) != 0 && (s->IntrStatus & PCSTimeout) == 0) {
+qemu_mod_timer(s->timer, next_time);
+}
+}
+
static void rtl8139_io_writel(void *opaque, uint8_t addr, uint32_t val)
{
RTL8139State *s = opaque;
@@ -2784,13 +2840,16 @@ static void rtl8139_io_writel(void *opaque, uint8_t
addr, uint32_t val)
case Timer:
DEBUG_PRINT(("RTL8139: TCTR Timer reset on write\n"));
-s->TCTR = 0;
s->TCTR_base = qemu_get_clock(vm_clock);
+rtl8139_set_next_tctr_time(s, s->TCTR_base);
break;
case FlashReg:
DEBUG_PRINT(("RTL8139: FlashReg TimerInt write val=0x%08x\n",
val));
-s->TimerInt = val;
+if (s->TimerInt != val) {
+s->TimerInt = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+}
break;
default:
@@ -3000,7 +3059,8 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t
addr)
break;
case Timer:
-re
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On 2/20/10, Rob Landley wrote: > On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: > > 2010/2/17 Rob Landley : > > > But it does imply that qemu is capable of decently running _something_ on > > > sparc, so the problems I'm seeing are more likely to be uClibc or > > > toolchain issues. > > > > qemu-sparc can decently run debian-40r8: gcc and all the other stuff > > seem to work. > > > > Most versions of the NetBSD boot. Some require the original OBP > > though. The only known to me version which definetely doesn't boot is > > 3.0.2. > > > > Also since the last dma fix Solaris 2.4-2.5.1 seems to be also fully > > functional. Don't have a suitable compiler to check whether it's > > working under Solaris though. > > > > Debian-40r8 should have all the necessary stuff to build the uClibc > > toolchain, right? > > So I did a network install of that Debian image into a 4 gig disk image, and > made some progress. > > First a quick bug report: qemu-system-sparc tries to set the video window to > 900 pixels vertical, but my laptop's display is only 800 pixels tall, and the > window manager trims it a bit more than that for the toolbar. The kernel > booting up seems to think the graphics window is still its original size > renders text off the bottom of it. But for some reason I can grab the window > and resize it, and when I do this the emulated kernel's frame buffer gets the > update and resizes its console to show the correct number of lines of text > for > the new size! (So my question is, why didn't it get the size right when the > window manager first resized it before I manually resized it again?) > > Anyway: yay emulated sparc debian, I installed it, got a reasonable > environment going, extracted my root filesystem image under there and > chrooted > into it... and everything worked fine. (Well, trying to run a dynamically > linked "hello world" still died with a bus error, but using the static > busybox > I could mount a tmpfs and list its contents, which I never could before.) > > My plan had been to use sparc-debian's copy of gdb to track down why the > binaries were going funky... but in that environment, they were behaving > themselves. Same binaries, built with the same toolchain, same qemu-system- > sparc, same -M and -cpu and so on... > > So I think "A-ha! Booting a different kernel! That's gotta be it!" > > The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.32 > kernel), but it installed the relevant .config in /boot, so I copied that out > with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter key > until > it shut up), stripped out all the modules and disabled module support, put > back in CONFIG_SERIAL_SUNZILOG_CONSOLE=y and friends, procfs, sysfs, and > tmpfs > (strange things to have as modules?), and CONFIG_SQUASHFS (that's my default > root filesystem format). > > I booted the result up with init=/bin/ash, did a "mount -t tmpfs /tmp /tmp", > and then: > > / # ls -l /tmp > Illegal instruction > > It's still misbehaving. Huh. > > This is as close as I can get to the debian kernel config without adding > module > support to my images (which is unnecessary complication for what they do). I > can try an ext2 root filesystem image but I don't see how that would cause > this. > > The part I don't understand is that same busybox binary, built with the same > toolchain, worked just fine under the Debian kernel. I'd blame my toolchain, > but in a slightly different context THE BINARIES WORKED... > > I don't understand what's going wrong here. Did the kernel break on sparc > sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc using > software emulated floating point at the kernel level and that's configured > as a > module? (Except I don't think busybox ls uses floating point...) Sparc32 is not maintained anymore so maybe it broke at some point. There was some discussion a few years ago. > Do any sparc people understand what's going on here? My next step is to grab > a 2.6.18 kernel and try to get _that_ to work with the tweaked debian config > (and an ext2 root filesystem since squashfs wasn't merged back then and had a > format change when it was merged). But I'm mostly flailing around blind > here... I'm also trying different kernels using my .config. But already 2.6.12 hangs in ESP probe.
[Qemu-devel] [PATCH] rewrote timer implementation for rtl8139.
Add a QEMU timer only when needed (timeout status not set, timeout
irq wanted and timer set).
This patch is required for Darwin. Patch has been tested under
FreeBSD, Darwin and Linux.
Signed-off-by: Frediano Ziglio
---
hw/rtl8139.c | 139 +++---
1 files changed, 84 insertions(+), 55 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index f04dd54..72e2242 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -41,6 +41,10 @@
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling
rx/tx operation
+ *
+ * 2010-Feb-04 Frediano Ziglio: Rewrote timer support using QEMU timer only
+ * when strictly needed (required for for
+ * Darwin)
*/
#include "hw.h"
@@ -60,9 +64,6 @@
/* Calculate CRCs properly on Rx packets */
#define RTL8139_CALCULATE_RXCRC 1
-/* Uncomment to enable on-board timer interrupts */
-//#define RTL8139_ONBOARD_TIMER 1
-
#if defined(RTL8139_CALCULATE_RXCRC)
/* For crc32 */
#include
@@ -491,9 +492,12 @@ typedef struct RTL8139State {
/* PCI interrupt timer */
QEMUTimer *timer;
+int64_t TimerExpire;
} RTL8139State;
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time);
+
static void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command)
{
DEBUG_PRINT(("RTL8139: eeprom command 0x%02x\n", command));
@@ -2522,7 +2526,9 @@ static void rtl8139_IntrMask_write(RTL8139State *s,
uint32_t val)
s->IntrMask = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
}
static uint32_t rtl8139_IntrMask_read(RTL8139State *s)
@@ -2555,12 +2561,22 @@ static void rtl8139_IntrStatus_write(RTL8139State *s,
uint32_t val)
rtl8139_update_irq(s);
s->IntrStatus = newStatus;
+/*
+ * Computing if we miss an interrupt here is not that correct but
+ * considered that we should have had already an interrupt
+ * and probably emulated is slower is better to assume this resetting was
+ * done before testing on previous rtl8139_update_irq lead to IRQ loosing
+ */
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
rtl8139_update_irq(s);
+
#endif
}
static uint32_t rtl8139_IntrStatus_read(RTL8139State *s)
{
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
uint32_t ret = s->IntrStatus;
DEBUG_PRINT(("RTL8139: IntrStatus read(w) val=0x%04x\n", ret));
@@ -2739,6 +2755,46 @@ static void rtl8139_io_writew(void *opaque, uint8_t
addr, uint32_t val)
}
}
+static void rtl8139_set_next_tctr_time(RTL8139State *s, int64_t current_time)
+{
+int64_t pci_time, next_time;
+uint32_t low_pci;
+
+DEBUG_PRINT(("RTL8139: entered rtl8139_set_next_tctr_time\n"));
+
+if (s->TimerExpire && current_time >= s->TimerExpire) {
+s->IntrStatus |= PCSTimeout;
+rtl8139_update_irq(s);
+}
+
+/* Set QEMU timer only if needed that is
+ * - TimerInt <> 0 (we have a timer)
+ * - mask = 1 (we want an interrupt timer)
+ * - irq = 0 (irq is not already active)
+ * If any of above change we need to compute timer again
+ * Also we must check if timer is passed without QEMU timer
+ */
+s->TimerExpire = 0;
+if (!s->TimerInt) {
+return;
+}
+
+pci_time = muldiv64(current_time - s->TCTR_base, PCI_FREQUENCY,
+get_ticks_per_sec());
+low_pci = pci_time & 0x;
+pci_time = pci_time - low_pci + s->TimerInt;
+if (low_pci >= s->TimerInt) {
+pci_time += 0x1LL;
+}
+next_time = s->TCTR_base + muldiv64(pci_time, get_ticks_per_sec(),
+PCI_FREQUENCY);
+s->TimerExpire = next_time;
+
+if ((s->IntrMask & PCSTimeout) != 0 && (s->IntrStatus & PCSTimeout) == 0) {
+qemu_mod_timer(s->timer, next_time);
+}
+}
+
static void rtl8139_io_writel(void *opaque, uint8_t addr, uint32_t val)
{
RTL8139State *s = opaque;
@@ -2784,13 +2840,16 @@ static void rtl8139_io_writel(void *opaque, uint8_t
addr, uint32_t val)
case Timer:
DEBUG_PRINT(("RTL8139: TCTR Timer reset on write\n"));
-s->TCTR = 0;
s->TCTR_base = qemu_get_clock(vm_clock);
+rtl8139_set_next_tctr_time(s, s->TCTR_base);
break;
case FlashReg:
DEBUG_PRINT(("RTL8139: FlashReg TimerInt write val=0x%08x\n",
val));
-s->TimerInt = val;
+if (s->TimerInt != val) {
+s->TimerInt = val;
+rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+}
break;
default:
@@ -3000,7 +3059,8 @@ static uint32_t rtl8139_io_readl(void *opaque, uint8_t
addr)
break;
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
On Sat, 20 Feb 2010, Lo?c Minier wrote: > On Sat, Feb 20, 2010, malc wrote: > > For instance this: > > http://sources.redhat.com/ml/libc-alpha/2005-06/msg00112.html > > > > The builtins are too coarse grained and will do more stuff than strictly > > necessary. > > Is this the case of the builtins I'm proposing to use? We could ask > for new ones without the drawbacks if any. > > Do you have another option to implement locking on thumb-2? No, i'm against using locking GCC builtins for all the other targets (well PPC), if they provide satisfactory results for thumb-2 please do submit an updated patch which uses them only for this host. -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] target-mips: fix CpU exception for coprocessor 0
When we signal a CpU exception for coprocessor 0, we should indicate
that it's for coprocessor 0 instead of coprocessor 1.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index dfea6f6..f3522f5 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -830,7 +830,7 @@ static inline void gen_op_addr_add (DisasContext *ctx, TCGv
ret, TCGv arg0, TCGv
static inline void check_cp0_enabled(DisasContext *ctx)
{
if (unlikely(!(ctx->hflags & MIPS_HFLAG_CP0)))
-generate_exception_err(ctx, EXCP_CpU, 1);
+generate_exception_err(ctx, EXCP_CpU, 0);
}
static inline void check_cp1_enabled(DisasContext *ctx)
--
1.6.3.2
[Qemu-devel] [PATCH] target-mips: fix ROTR and DROTR by zero
Signed-off-by: Nathan Froyd
---
target-mips/translate.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index dfea6f6..de5ac18 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1476,6 +1476,8 @@ static void gen_shift_imm(CPUState *env, DisasContext
*ctx, uint32_t opc,
tcg_gen_rotri_i32(t1, t1, uimm);
tcg_gen_ext_i32_tl(cpu_gpr[rt], t1);
tcg_temp_free_i32(t1);
+} else {
+tcg_gen_ext32s_tl(cpu_gpr[rt], t0);
}
opn = "rotr";
break;
@@ -1495,6 +1497,8 @@ static void gen_shift_imm(CPUState *env, DisasContext
*ctx, uint32_t opc,
case OPC_DROTR:
if (uimm != 0) {
tcg_gen_rotri_tl(cpu_gpr[rt], t0, uimm);
+} else {
+tcg_gen_mov_tl(cpu_gpr[rt], t0);
}
opn = "drotr";
break;
--
1.6.3.2
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On Saturday 20 February 2010 11:34:44 Blue Swirl wrote: > On 2/20/10, Rob Landley wrote: > > I don't understand what's going wrong here. Did the kernel break on > > sparc sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc > > using software emulated floating point at the kernel level and that's > > configured as a module? (Except I don't think busybox ls uses floating > > point...) > > Sparc32 is not maintained anymore so maybe it broke at some point. > There was some discussion a few years ago. Not maintained on the Linux kernel side, or not maintained under qemu? It seems to be working under debian, but the 2.6.18 kernel is from 2006. > > Do any sparc people understand what's going on here? My next step is to > > grab a 2.6.18 kernel and try to get _that_ to work with the tweaked > > debian config (and an ext2 root filesystem since squashfs wasn't merged > > back then and had a format change when it was merged). But I'm mostly > > flailing around blind here... > > I'm also trying different kernels using my .config. But already 2.6.12 > hangs in ESP probe. I've got 2.6.32 booting to a command prompt (albeit with serial console and intentionall restricted set of hardware). But then it misbehaves. I'll try getting 2.6.18 to build with a known .config, and then bisect forward if that seems to work... Thanks, Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On Sat, Feb 20, 2010 at 11:03:41AM -0600, Anthony Liguori wrote:
> Date: Sat, 20 Feb 2010 11:03:41 -0600
> From: Anthony Liguori
> To: "David S. Ahern"
> Cc: Dor Laor , Shahar Havivi ,
> qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
> using /dev/tty monitor
>
> On 02/20/2010 09:18 AM, David S. Ahern wrote:
> >On 02/20/2010 01:30 AM, Shahar Havivi wrote:
> >>when exiting qemu that run with "-monitor /dev/tty", the launching
> >>terminal get weird behaviour because no restore terminals action has
> >>taken.
> >>added chr_close and register atexit() code for tty devices (like stdio
> >>does)
> >>
> >>Signed-off-by: Shahar Havivi
> >>---
> >> qemu-char.c | 14 ++
> >> 1 files changed, 14 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/qemu-char.c b/qemu-char.c
> >>index 75dbf66..de16883 100644
> >>--- a/qemu-char.c
> >>+++ b/qemu-char.c
> >>@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
> >> speed, parity, data_bits, stop_bits);
> >> #endif
> >> tcgetattr (fd,&tty);
> >>+oldtty = tty;
> >>
> >> #define check_speed(val) if (speed<= val) { spd = B##val; break; }
> >> speed = speed * 10 / 11;
> >>@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr,
> >>int cmd, void *arg)
> >> return 0;
> >> }
> >>
> >>+static void tty_exit(void)
> >>+{
> >>+tcsetattr(0, TCSANOW,&oldtty);
> >>+}
> >>+
> >>+static void qemu_chr_close_tty(struct CharDriverState *chr)
> >>+{
> >>+tty_exit();
> >>+fd_chr_close(chr);
> >>+}
> >
> >The close callback needs to close the fd for the device as well. I have
> >sent a patch to handle this; waiting for it to be included:
> >
> >http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
>
> It didn't apply with git-am. I'm not sure why, am investigating now.
>
> Regards,
>
> Anthony Liguori
>
Note that the method fd_chr_close() is closing the fd_in, no need to the
close logic again, and when opening a monitor with /dev/tty the
chr->chr_close not called that is why you need to register with
atexit(). (same as stdio monitor does).
Shahar.
> >David
> >
> >
> >>+
> >> static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
> >> {
> >> const char *filename = qemu_opt_get(opts, "path");
> >>@@ -1190,6 +1202,8 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts
> >>*opts)
> >> return NULL;
> >> }
> >> chr->chr_ioctl = tty_serial_ioctl;
> >>+chr->chr_close = qemu_chr_close_tty;
> >>+atexit(tty_exit);
> >> return chr;
> >> }
> >> #else /* ! __linux__&& ! __sun__ */
> >
> >
>
>
>
[Qemu-devel] [PATCH 1/3] tcg-hppa: Fix const errors in hppa-dis.c.
---
hppa-dis.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hppa-dis.c b/hppa-dis.c
index 9d96d72..49f99c8 100644
--- a/hppa-dis.c
+++ b/hppa-dis.c
@@ -576,7 +576,7 @@ struct pa_opcode
const char *name;
unsigned long int match; /* Bits that must be set... */
unsigned long int mask;/* ... in these bits. */
-char *args;
+const char *args;
enum pa_arch arch;
char flags;
};
@@ -2753,7 +2753,7 @@ print_insn_hppa (bfd_vma memaddr, disassemble_info *info)
int sf = GET_FIELD (insn, 19, 20);
const char * const * source = float_format_names;
const char * const * dest = float_format_names;
- char *t = "";
+ const char *t = "";
if (sub == 4)
{
--
1.6.6
[Qemu-devel] [PATCH 2/3] tcg-hppa: Fix 64-bit argument ordering.
--- tcg/tcg.c | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/tcg/tcg.c b/tcg/tcg.c index e6a1caf..32345cc 100644 --- a/tcg/tcg.c +++ b/tcg/tcg.c @@ -596,7 +596,17 @@ void tcg_gen_callN(TCGContext *s, TCGv_ptr func, unsigned int flags, real_args++; } #endif -#ifdef TCG_TARGET_WORDS_BIGENDIAN + /* If stack grows up, then we will be placing successive + arguments at lower addresses, which means we need to + reverse the order compared to how we would normally + treat either big or little-endian. For those arguments + that will wind up in registers, this still works for + HPPA (the only current STACK_GROWSUP target) since the + argument registers are *also* allocated in decreasing + order. If another such target is added, this logic may + have to get more complicated to differentiate between + stack arguments and register arguments. */ +#if defined(TCG_TARGET_WORDS_BIGENDIAN) != defined(TCG_TARGET_STACK_GROWSUP) *gen_opparam_ptr++ = args[i] + 1; *gen_opparam_ptr++ = args[i]; #else -- 1.6.6
[Qemu-devel] [PATCH 0/3] Get tcg-hppa working
Tested on debian/parisc (pa8600, 32-bit), and is good enough to run the linux-user-test-0.3 binaries for arm, armeb, i386, mips, mipsel, sh4, and sh4eb. It still fails for ppc and sparc userland; that'll take more debugging. I had a go at sparc-test-0.2, since that's the only one that reliably works for me on x86_64 with -nographics, but there seems to be some sort of signalling problem. The trace makes it into the idle loop and never makes it out again. Anyway, it's a distinct improvement over the current state of affairs, and at least mostly works. r~ Richard Henderson (3): tcg-hppa: Fix const errors in hppa-dis.c. tcg-hppa: Fix 64-bit argument ordering. tcg-hppa: Finish the port. configure |5 +- hppa-dis.c|4 +- tcg/hppa/tcg-target.c | 1847 +++-- tcg/hppa/tcg-target.h | 141 +--- tcg/tcg.c | 12 +- 5 files changed, 1356 insertions(+), 653 deletions(-)
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On Sat, Feb 20, 2010 at 11:47:52AM -0800, Richard Henderson wrote: > Tested on debian/parisc (pa8600, 32-bit), and is good enough to run > the linux-user-test-0.3 binaries for arm, armeb, i386, mips, mipsel, > sh4, and sh4eb. It still fails for ppc and sparc userland; that'll > take more debugging. > > I had a go at sparc-test-0.2, since that's the only one that reliably > works for me on x86_64 with -nographics, but there seems to be some > sort of signalling problem. The trace makes it into the idle loop > and never makes it out again. Nice! The qemu_ld / qemu_st cleanup strikes me as something that would be appropriate for some other TCG targets too, once this has been applied. The first thing that I do when I find the time will be to get TCI working fully on 32-bit archs... then I'll see what I can do to try to track down the remaining issues. Cheers, -- Stuart Brady
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
2010/2/20 Blue Swirl : > On 2/20/10, Rob Landley wrote: >> On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: >> > 2010/2/17 Rob Landley : >> > > But it does imply that qemu is capable of decently running _something_ >> on >> > > sparc, so the problems I'm seeing are more likely to be uClibc or >> > > toolchain issues. >> > >> > qemu-sparc can decently run debian-40r8: gcc and all the other stuff >> > seem to work. >> > >> > Most versions of the NetBSD boot. Some require the original OBP >> > though. The only known to me version which definetely doesn't boot is >> > 3.0.2. >> > >> > Also since the last dma fix Solaris 2.4-2.5.1 seems to be also fully >> > functional. Don't have a suitable compiler to check whether it's >> > working under Solaris though. >> > >> > Debian-40r8 should have all the necessary stuff to build the uClibc >> > toolchain, right? >> >> So I did a network install of that Debian image into a 4 gig disk image, and >> made some progress. >> >> First a quick bug report: qemu-system-sparc tries to set the video window to >> 900 pixels vertical, but my laptop's display is only 800 pixels tall, and >> the >> window manager trims it a bit more than that for the toolbar. The kernel >> booting up seems to think the graphics window is still its original size >> renders text off the bottom of it. But for some reason I can grab the >> window >> and resize it, and when I do this the emulated kernel's frame buffer gets >> the >> update and resizes its console to show the correct number of lines of text >> for >> the new size! (So my question is, why didn't it get the size right when the >> window manager first resized it before I manually resized it again?) >> >> Anyway: yay emulated sparc debian, I installed it, got a reasonable >> environment going, extracted my root filesystem image under there and >> chrooted >> into it... and everything worked fine. (Well, trying to run a dynamically >> linked "hello world" still died with a bus error, but using the static >> busybox >> I could mount a tmpfs and list its contents, which I never could before.) >> >> My plan had been to use sparc-debian's copy of gdb to track down why the >> binaries were going funky... but in that environment, they were behaving >> themselves. Same binaries, built with the same toolchain, same qemu-system- >> sparc, same -M and -cpu and so on... >> >> So I think "A-ha! Booting a different kernel! That's gotta be it!" >> >> The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.32 >> kernel), but it installed the relevant .config in /boot, so I copied that >> out >> with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter key >> until >> it shut up), stripped out all the modules and disabled module support, put >> back in CONFIG_SERIAL_SUNZILOG_CONSOLE=y and friends, procfs, sysfs, and >> tmpfs >> (strange things to have as modules?), and CONFIG_SQUASHFS (that's my default >> root filesystem format). >> >> I booted the result up with init=/bin/ash, did a "mount -t tmpfs /tmp /tmp", >> and then: >> >> / # ls -l /tmp >> Illegal instruction >> >> It's still misbehaving. Huh. >> >> This is as close as I can get to the debian kernel config without adding >> module >> support to my images (which is unnecessary complication for what they do). >> I >> can try an ext2 root filesystem image but I don't see how that would cause >> this. >> >> The part I don't understand is that same busybox binary, built with the same >> toolchain, worked just fine under the Debian kernel. I'd blame my >> toolchain, >> but in a slightly different context THE BINARIES WORKED... >> >> I don't understand what's going wrong here. Did the kernel break on sparc >> sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc using >> software emulated floating point at the kernel level and that's configured >> as a >> module? (Except I don't think busybox ls uses floating point...) > > Sparc32 is not maintained anymore so maybe it broke at some point. > There was some discussion a few years ago. > >> Do any sparc people understand what's going on here? My next step is to >> grab >> a 2.6.18 kernel and try to get _that_ to work with the tweaked debian config >> (and an ext2 root filesystem since squashfs wasn't merged back then and had >> a >> format change when it was merged). But I'm mostly flailing around blind >> here... > > I'm also trying different kernels using my .config. But already 2.6.12 > hangs in ESP probe. Does it work on a real hw? 2.6.18 definitely does. We still have bug(s) in ESP though: Solaris also hangs in ESP probe after a soft reset in OBP. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On Sat, 20 Feb 2010, Stuart Brady wrote: > On Sat, Feb 20, 2010 at 11:47:52AM -0800, Richard Henderson wrote: > > Tested on debian/parisc (pa8600, 32-bit), and is good enough to run > > the linux-user-test-0.3 binaries for arm, armeb, i386, mips, mipsel, > > sh4, and sh4eb. It still fails for ppc and sparc userland; that'll > > take more debugging. > > > > I had a go at sparc-test-0.2, since that's the only one that reliably > > works for me on x86_64 with -nographics, but there seems to be some > > sort of signalling problem. The trace makes it into the idle loop > > and never makes it out again. > > Nice! > > The qemu_ld / qemu_st cleanup strikes me as something that would be > appropriate for some other TCG targets too, once this has been applied. Care to point out what this cleanup is, my HPPA-fu is around zero. > The first thing that I do when I find the time will be to get TCI > working fully on 32-bit archs... then I'll see what I can do to try to > track down the remaining issues. > > Cheers, > -- mailto:av1...@comtv.ru
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On 2/20/10, Rob Landley wrote: > On Saturday 20 February 2010 11:34:44 Blue Swirl wrote: > > On 2/20/10, Rob Landley wrote: > > > > I don't understand what's going wrong here. Did the kernel break on > > > sparc sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc > > > using software emulated floating point at the kernel level and that's > > > configured as a module? (Except I don't think busybox ls uses floating > > > point...) > > > > Sparc32 is not maintained anymore so maybe it broke at some point. > > There was some discussion a few years ago. > > > Not maintained on the Linux kernel side, or not maintained under qemu? It > seems to be working under debian, but the 2.6.18 kernel is from 2006. On kernel side. I try to maintain QEMU side. > > > Do any sparc people understand what's going on here? My next step is to > > > grab a 2.6.18 kernel and try to get _that_ to work with the tweaked > > > debian config (and an ext2 root filesystem since squashfs wasn't merged > > > back then and had a format change when it was merged). But I'm mostly > > > flailing around blind here... > > > > I'm also trying different kernels using my .config. But already 2.6.12 > > hangs in ESP probe. > > > I've got 2.6.32 booting to a command prompt (albeit with serial console and > intentionall restricted set of hardware). But then it misbehaves. > > I'll try getting 2.6.18 to build with a known .config, and then bisect > forward > if that seems to work... Good plan. Bisecting backwards could be interesting too, to find out which releases are actually working out of the box.
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
2010/2/20 Rob Landley : > On Saturday 20 February 2010 11:34:44 Blue Swirl wrote: >> On 2/20/10, Rob Landley wrote: >> > I don't understand what's going wrong here. Did the kernel break on >> > sparc sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc >> > using software emulated floating point at the kernel level and that's >> > configured as a module? (Except I don't think busybox ls uses floating >> > point...) >> >> Sparc32 is not maintained anymore so maybe it broke at some point. >> There was some discussion a few years ago. > > Not maintained on the Linux kernel side, or not maintained under qemu? It > seems to be working under debian, but the 2.6.18 kernel is from 2006. > >> > Do any sparc people understand what's going on here? My next step is to >> > grab a 2.6.18 kernel and try to get _that_ to work with the tweaked >> > debian config (and an ext2 root filesystem since squashfs wasn't merged >> > back then and had a format change when it was merged). But I'm mostly >> > flailing around blind here... >> >> I'm also trying different kernels using my .config. But already 2.6.12 >> hangs in ESP probe. > > I've got 2.6.32 booting to a command prompt (albeit with serial console and > intentionall restricted set of hardware). But then it misbehaves. > > I'll try getting 2.6.18 to build with a known .config, and then bisect forward > if that seems to work... You can also try aurora linux. They had a bit newer kernel. Don't know how stable is it on a real hw though. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On 2/20/10, Artyom Tarasenko wrote: > 2010/2/20 Blue Swirl : > > > On 2/20/10, Rob Landley wrote: > >> On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: > >> > 2010/2/17 Rob Landley : > >> > > But it does imply that qemu is capable of decently running > _something_ on > >> > > sparc, so the problems I'm seeing are more likely to be uClibc or > >> > > toolchain issues. > >> > > >> > qemu-sparc can decently run debian-40r8: gcc and all the other stuff > >> > seem to work. > >> > > >> > Most versions of the NetBSD boot. Some require the original OBP > >> > though. The only known to me version which definetely doesn't boot is > >> > 3.0.2. > >> > > >> > Also since the last dma fix Solaris 2.4-2.5.1 seems to be also fully > >> > functional. Don't have a suitable compiler to check whether it's > >> > working under Solaris though. > >> > > >> > Debian-40r8 should have all the necessary stuff to build the uClibc > >> > toolchain, right? > >> > >> So I did a network install of that Debian image into a 4 gig disk image, > and > >> made some progress. > >> > >> First a quick bug report: qemu-system-sparc tries to set the video > window to > >> 900 pixels vertical, but my laptop's display is only 800 pixels tall, > and the > >> window manager trims it a bit more than that for the toolbar. The kernel > >> booting up seems to think the graphics window is still its original size > >> renders text off the bottom of it. But for some reason I can grab the > window > >> and resize it, and when I do this the emulated kernel's frame buffer > gets the > >> update and resizes its console to show the correct number of lines of > text for > >> the new size! (So my question is, why didn't it get the size right when > the > >> window manager first resized it before I manually resized it again?) > >> > >> Anyway: yay emulated sparc debian, I installed it, got a reasonable > >> environment going, extracted my root filesystem image under there and > chrooted > >> into it... and everything worked fine. (Well, trying to run a > dynamically > >> linked "hello world" still died with a bus error, but using the static > busybox > >> I could mount a tmpfs and list its contents, which I never could before.) > >> > >> My plan had been to use sparc-debian's copy of gdb to track down why the > >> binaries were going funky... but in that environment, they were behaving > >> themselves. Same binaries, built with the same toolchain, same > qemu-system- > >> sparc, same -M and -cpu and so on... > >> > >> So I think "A-ha! Booting a different kernel! That's gotta be it!" > >> > >> The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.32 > >> kernel), but it installed the relevant .config in /boot, so I copied > that out > >> with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter > key until > >> it shut up), stripped out all the modules and disabled module support, > put > >> back in CONFIG_SERIAL_SUNZILOG_CONSOLE=y and friends, procfs, sysfs, and > tmpfs > >> (strange things to have as modules?), and CONFIG_SQUASHFS (that's my > default > >> root filesystem format). > >> > >> I booted the result up with init=/bin/ash, did a "mount -t tmpfs /tmp > /tmp", > >> and then: > >> > >> / # ls -l /tmp > >> Illegal instruction > >> > >> It's still misbehaving. Huh. > >> > >> This is as close as I can get to the debian kernel config without adding > module > >> support to my images (which is unnecessary complication for what they > do). I > >> can try an ext2 root filesystem image but I don't see how that would > cause > >> this. > >> > >> The part I don't understand is that same busybox binary, built with the > same > >> toolchain, worked just fine under the Debian kernel. I'd blame my > toolchain, > >> but in a slightly different context THE BINARIES WORKED... > >> > >> I don't understand what's going wrong here. Did the kernel break on > sparc > >> sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc using > >> software emulated floating point at the kernel level and that's > configured as a > >> module? (Except I don't think busybox ls uses floating point...) > > > > Sparc32 is not maintained anymore so maybe it broke at some point. > > There was some discussion a few years ago. > > > >> Do any sparc people understand what's going on here? My next step is to > grab > >> a 2.6.18 kernel and try to get _that_ to work with the tweaked debian > config > >> (and an ext2 root filesystem since squashfs wasn't merged back then and > had a > >> format change when it was merged). But I'm mostly flailing around blind > >> here... > > > > I'm also trying different kernels using my .config. But already 2.6.12 > > hangs in ESP probe. > > > Does it work on a real hw? 2.6.18 definitely does. > We still have bug(s) in ESP t
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On Sun, Feb 21, 2010 at 12:54:46AM +0300, malc wrote: > On Sat, 20 Feb 2010, Stuart Brady wrote: > > > The qemu_ld / qemu_st cleanup strikes me as something that would be > > appropriate for some other TCG targets too, once this has been applied. > > Care to point out what this cleanup is, my HPPA-fu is around zero. The 'split out TLB reads from qemu_ld and qemu_st' part of patch 3, which adds a new tcg_out_tlb_read() function. That code is duplicated in tcg_out_qemu_ld() and tcg_out_qemu_st() for all archs except PPC64. It just makes the code that little bit more readable. Cheers, -- Stuart Brady
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On 02/20/2010 01:54 PM, malc wrote: The qemu_ld / qemu_st cleanup strikes me as something that would be appropriate for some other TCG targets too, once this has been applied. Care to point out what this cleanup is, my HPPA-fu is around zero. Split out a tlb_read function from qemu_ld/qemu_st, as is already done on ppc64. r~
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On Sat, 20 Feb 2010, Richard Henderson wrote: > On 02/20/2010 01:54 PM, malc wrote: > > > The qemu_ld / qemu_st cleanup strikes me as something that would be > > > appropriate for some other TCG targets too, once this has been applied. > > > > Care to point out what this cleanup is, my HPPA-fu is around zero. > > Split out a tlb_read function from qemu_ld/qemu_st, > as is already done on ppc64. > Ah, so i already half did it, good to know. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On Sat, 20 Feb 2010, Stuart Brady wrote: > On Sun, Feb 21, 2010 at 12:54:46AM +0300, malc wrote: > > On Sat, 20 Feb 2010, Stuart Brady wrote: > > > > > The qemu_ld / qemu_st cleanup strikes me as something that would be > > > appropriate for some other TCG targets too, once this has been applied. > > > > Care to point out what this cleanup is, my HPPA-fu is around zero. > > The 'split out TLB reads from qemu_ld and qemu_st' part of patch 3, > which adds a new tcg_out_tlb_read() function. That code is duplicated > in tcg_out_qemu_ld() and tcg_out_qemu_st() for all archs except PPC64. > It just makes the code that little bit more readable. > Thanks. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 0/3] Get tcg-hppa working
On 02/20/2010 02:22 PM, malc wrote: Ah, so i already half did it, good to know. I stole several good ideas from the ppc64 port. ;-) That one and using indexed loads to handle GUEST_BASE. r~
[Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)
On Saturday 20 February 2010 15:59:31 Blue Swirl wrote: > > I've got 2.6.32 booting to a command prompt (albeit with serial console > > and intentionall restricted set of hardware). But then it misbehaves. > > > > I'll try getting 2.6.18 to build with a known .config, and then bisect > > forward if that seems to work... > > Good plan. Bisecting backwards could be interesting too, to find out > which releases are actually working out of the box. I started by iterating through the release versions. It's working up through 2.6.28, then 2.6.29 has the out of memory error in my init script. Bisecting now... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
[Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
When booting a Juniper JunOS kernel (FreeBSD based) I am getting a panic: unkown/reserved trap error immediately after the kernel loads. If i use an older pc-bios with the '-bios' option everything works so it seems to be an issue with the SeaBios. With #DEBUG_BIOS enabled in hw/pc.c here is what i am getting during boot. bbenn...@strongbad:~/Lab/JNCIP-M$ qemu -m 512m -hda olive-base-8.1R4.3.img -cdrom 4.11-RELEASE-i386-miniinst.iso -boot c -localtime -nographic Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Ram Size=0x2000 (0x high) CPU Mhz=3000 Found 1 cpu(s) max supported 1 cpu(s) PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xe000 region 1: 0xe200 region 6: 0xe201 PCI: bus=0 devfn=0x18: vendor_id=0x8086 device_id=0x100e region 0: 0xe202 region 1: 0xc040 region 6: 0xe204 MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 SMBIOS ptr=0x000f8990 table=0x1ef0 ACPI tables: RSDP=0x000f8960 RSDT=0x1fffde30 Scan for VGA option rom Running option rom at c000:0003 VGABios $Id$ Turning on vga console Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Found 1 lpt ports Found 1 serial ports ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) ATA controller 1 at 170/374/c008 (irq 15 dev 9) ps2 irq but no data. ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 ps2_recvbyte timeout keyboard initialized Scan for option roms Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm call arg1=2 pmm call arg1=0 Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 1fffd000 = 1 4: 1fffd000 - 2000 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from Hard Disk... Booting from :7c00 Console: serial port BIOS drive C: is disk0 BIOS 637kB/523252kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 (buil...@vouivre.juniper.net, Fri Aug 24 16:01:34 GMT 2007) Loading /boot/defaults/loader.conf /boot/installer text=0x24c77f data=0x2aa7c+0x38462 syms=[0x4+0x3a420+0x4+0x454ac] | Hit [Enter] to boot immediately, or space bar for command prompt. Booting [installer]... kernel trap 12 with interrupts disabled instruction pointer = 0x8:0xc02ebc3e stack pointer = 0x10:0xc07f9edc frame pointer = 0x10:0xc07f9f34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = Idle interrupt mask = net tty bio cam trap number = 30 dog: ERROR - reset of uninitialized watchdog panic: unknown/reserved trap (null)(c037dbc0,c037dbc0,c032d5c4,c07f9df0,5) at0 (null)(c032d5c4,1e,c07f9f34,0,0) at0 (null)(c07f9e9c,0,c07f9ef4,c01951ed) at0 (null)(10,10,10,0,c) at0 (null)(10,10,10,0,7fe000) at0 (null)(2) at0 (null)(c07f9ff4,c02e569c,0,81,7fe000) at0 (null)(c07f9fd4,f,3,8,0) at0 (null)(7fe000,0,0,0,0) at0 (null)() at0 dog: ERROR - reset of uninitialized watchdog dog: ERROR - reset of uninitialized watchdog Uptime: 0s Any help or direction on where to look further or options to try would be great. Thanks, -Brandon Bennett
Re: [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
On Sat, Feb 20, 2010 at 05:23:59PM -0700, Brandon Bennett wrote: > When booting a Juniper JunOS kernel (FreeBSD based) I am getting a > panic: unkown/reserved trap error immediately after the kernel loads. > If i use an older pc-bios with the '-bios' option everything works so > it seems to be an issue with the SeaBios. > > With #DEBUG_BIOS enabled in hw/pc.c here is what i am getting during boot. Thanks Brandon, I don't see anything in the log that looks suscpicious. Are these JunOS images available for download somewhere? > Any help or direction on where to look further or options to try would be > great. Should a kernel fail during boot, I'd suspect it doesn't like one of the apm/pcibios callbacks, or it doesn't like one of the smbios/mptable/acpi tables. You could try compiling the SeaBIOS code (see http://seabios.org/Download ) and increasing the debugging by modifying src/config.h. Specifically, you could increase CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to 1. Also, you could try disabling some of the features to see if that prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / CONFIG_MPTABLE). -Kevin
