Re: [Qemu-devel] [PATCH] add serial port mux for debug monitor support
Following up to my last patch, I noticed a break; statement was missing
and cause a bit of a problem with the -echr option.
Fix is attached.
signed-off-by: [EMAIL PROTECTED]
Jason Wessel wrote:
There are two patches attached to show the logical progress of the
code and in the case that one is not accepted the work is more easily
broken down.
The serial_mux_driver.patch must be applied first. It adds a generic
mux support for the I/O drivers internal to vl.c. The main purpose is
to use it for switching on the monitor. Basically it allows more than
one driver to register an fd_read and fd_can_read routine. Of course
the mux support is generic and could easily be used for other sorts of
I/O. This patch also adds the new options:
-echr ascii_value -- Allow you to use a different control character
other than Control-a
-serial mon:device_string -- Multiplex the device_string with the
monitor functionality
The second patch fully abstracts the monitor so that the monitor can
be used on more than one serial port at the same time as well as
having a separate dedicated monitor. I also removed the stdio
splitting from the stdio driver. The mux driver can be used to
replace any functionality that I missed.
signed-off-by: [EMAIL PROTECTED]
Jason.
Index: qemu/vl.c
===
--- qemu.orig/vl.c
+++ qemu/vl.c
@@ -6036,6 +6036,7 @@ int main(int argc, char **argv)
term_escape_char = strtol(optarg, &r, 0);
if (r == optarg)
printf("Bad argument to echr\n");
+break;
}
case QEMU_OPTION_monitor:
pstrcpy(monitor_device, sizeof(monitor_device), optarg);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Sparc64 host support, PPC soft float
I converted PPC to use soft float instead of native FPU. I don't have much PPC software available, but at least some qemu-tests files work on an x86 host. As I also fixed the bug with system emulators not passing final link (in sparc64.ld), now all default user and softmmu targets can be built on a Sparc64 host. The native FPU is still used for x86 targets, for example in fild and fadd. Sparc32/64 can't move stuff from integer registers to FPU directly, some memory buffer must be used in between. GCC allocates a stack frame for this, but due to bug in save instruction offset check in dyngen.c, it's not noticed. Maybe I'll fix these too. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ppc_softfloat.diff.bz2 Description: Binary data sparc64_host.diff.bz2 Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote:
You should add a runtime selection system : see the ARM and PowerPC
targets (I would prefer a parameter to cpu_init(). It was not done that
way on PowerPC for legacy reasons). Each machine should be able to
select the processor it needs (and allow the user to change it if
needed, but it is not the main point). There is no good reason to make
the selection at compile time because the translator can efficiently
handle any CPU differences at runtime.
Find in the attachment a first proposal for runtime
instruction set configuration for MIPS target. Please
comment, correct etc.
Some notes:
- As first step, only three options for R4K, NEC (partly,
see below) and FPU are used. The different MIPS ISA levels
aren't used at the moment and are there for future use.
Fabrice mentioned that he likes to split the different MIPS
intstruction set configurations clearly.
- As I understand it, MIPS III is an extension of MIPS II,
MIPS IV is an extension of MIPS III etc. Therefore I used
definitions for ISAx which include the smaller ones as well.
- With the
#ifdef MIPS_USES_xxx
#define mips_uses_xxx() (env->features & MIPS_FEATURE_xxx)
#else
#define mips_uses_xxx() 0
#endif
logic it should be possible to enable or disable a feature
at compile time by setting the corresponding macro *or* at
runtime by adding machines with different features to
cpu_mips_set_model().
- If mips_uses_xxx() is set to 0 at compile time, I think
gcc should optimize away the if(mips_uses_xxx()) parts in
translate.c. Therefore I think we can remove some #if
defined (MIPS_USES_xxx).
- An cpu_mips_set_model() is introduced similiar to the ARM
one. Because in mips-defs.h there was a hardcoded CPU, some
reorganization for runtime selection was necessary.
- Later, it should be possible to move more options to
runtime configuration, like endianess and the #if defined
(MIPS_CONFIGx) in cpu_mips_init(). For the moment, to keep
patch small I concentrated only on instruction set. I don't
want to mix to much instruction set configuration and
machine runtime selection for the moment.
- cpu_mips_init() moved from translate.c to helper.c and was
extended there by set_feature() and cpu_mips_set_model()
(same file location like used by ARM). Setting of FPU
options moved from cpu_mips_init() to model configuration
cpu_mips_set_model().
- My patch for NEC instruction set extension (the main
reason for the whole stuff ;) ) will be send and updated if
you like the configuration in this patch and something like
this is applied. For the moment, there's only a stub in
decode_opc() which should generate an exception.
Best regards
Dirk
--- ./target-mips/cpu.h_orig2006-07-02 14:44:59.0 +0200
+++ ./target-mips/cpu.h 2006-07-02 17:32:41.0 +0200
@@ -210,6 +210,8 @@ struct CPUMIPSState {
int bcond; /* Branch condition (if needed) */
int halted; /* TRUE if the CPU is in suspend state */
+
+uint32_t features; /* Internal CPU feature flags */
CPU_COMMON
};
@@ -275,5 +277,58 @@ enum {
int cpu_mips_exec(CPUMIPSState *s);
CPUMIPSState *cpu_mips_init(void);
uint32_t cpu_mips_get_clock (void);
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
+
+enum mips_features {
+MIPS_FEATURE_ISA1 = 0x1, /* MIPS I instruction set architecture */
+MIPS_FEATURE_ISA2 = 0x3, /* MIPS II instruction set architecture */
+MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
+MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV instruction set architecture */
+MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */
+MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */
+MIPS_FEATURE_FPU = 0x40, /* floating point instruction set */
+};
+
+#ifdef MIPS_USES_ISA1
+#define mips_uses_isa1() (env->features & MIPS_FEATURE_ISA1)
+#else
+#define mips_uses_isa1() 0
+#endif
+
+#ifdef MIPS_USES_ISA2
+#define mips_uses_isa2() (env->features & MIPS_FEATURE_ISA2)
+#else
+#define mips_uses_isa2() 0
+#endif
+
+#ifdef MIPS_USES_ISA3
+#define mips_uses_isa3() (env->features & MIPS_FEATURE_ISA3)
+#else
+#define mips_uses_isa3() 0
+#endif
+
+#ifdef MIPS_USES_ISA4
+#define mips_uses_isa4() (env->features & MIPS_FEATURE_ISA4)
+#else
+#define mips_uses_isa4() 0
+#endif
+
+#ifdef MIPS_USES_R4K_EXT
+#define mips_uses_r4k_ext() (env->features & MIPS_FEATURE_R4K_EXT)
+#else
+#define mips_uses_r4k_ext() 0
+#endif
+
+#ifdef MIPS_FEATURE_NEC_EXT
+#define mips_uses_nec_ext() (env->features & MIPS_FEATURE_NEC_EXT)
+#else
+#define mips_uses_nec_ext() 0
+#endif
+
+#ifdef MIPS_USES_FPU
+#define mips_uses_fpu() (env->features & MIPS_FEATURE_FPU)
+#else
+#define mips_uses_fpu() 0
+#endif
#endif /* !defined (__MIPS_CPU_H__) */
--- ./target-mips/helper.c_orig 2006-07-02 15:30:49.0 +0200
+++ ./target-mips/helper.c 2006-07-02 17:41:01.0 +0200
@@ -430,3 +430,69 @@ void do_interrupt (CPUState *env)
}
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Dirk Behme wrote:
> Fabrice Bellard wrote:
> >You should add a runtime selection system : see the ARM and PowerPC
> >targets (I would prefer a parameter to cpu_init(). It was not done that
> >way on PowerPC for legacy reasons). Each machine should be able to
> >select the processor it needs (and allow the user to change it if
> >needed, but it is not the main point).
It might be interesting for MIPS to decouple Machine and CPU somewhat.
E.g. the Malta board supports a number of different 32- and 64-bit CPUs.
> >There is no good reason to make
> >the selection at compile time because the translator can efficiently
> >handle any CPU differences at runtime.
I'm a bit dubious about this argument, each instruction needs to be
checked agains a tuple of values. How much performance loss would be
acceptable?
> Find in the attachment a first proposal for runtime
> instruction set configuration for MIPS target. Please
> comment, correct etc.
>
> Some notes:
>
> - As first step, only three options for R4K, NEC (partly,
> see below) and FPU are used. The different MIPS ISA levels
> aren't used at the moment and are there for future use.
> Fabrice mentioned that he likes to split the different MIPS
> intstruction set configurations clearly.
>
> - As I understand it, MIPS III is an extension of MIPS II,
> MIPS IV is an extension of MIPS III etc. Therefore I used
> definitions for ISAx which include the smaller ones as well.
Unfortunately it is not that simple. We have the upward-compatible ISAs:
--> III -> IV -> V -> 64 -> 64R2 (64-bit)
/ ^ ^
| / /
I -> II -> 32 -> 32R2 (32-bit)
plus CPU-specific extensions. For pre-MIPS32 the CP0 instructions are
also CPU-specific, but they are needed for useful CPU emulation. The
GNU toolchain solves this by declaring some specific CPUs to ISA models
(R3000 for MIPS-I, R6000 for MIPS-II, and R4000 for MIPS-III), and
handles their instructions as if they were part of the ISA. Qemu should
IMHO use the same scheme.
The floating point instructions need also some finer granularity, most
ISAs extended the FP instruction set as well.
All of the above still doesn't handle the ASEs, like MIPS16, MIPS3D,
the DSP extensions, etc.
Binutils uses a ISA-ASE-CPU-HAS_FP tuple, since this is at least good
enough for code generation I figure it is also ok for emulation.
> @@ -275,5 +277,58 @@ enum {
> int cpu_mips_exec(CPUMIPSState *s);
> CPUMIPSState *cpu_mips_init(void);
> uint32_t cpu_mips_get_clock (void);
> +void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
> +
> +enum mips_features {
> +MIPS_FEATURE_ISA1 = 0x1, /* MIPS I instruction set architecture */
> +MIPS_FEATURE_ISA2 = 0x3, /* MIPS II instruction set architecture */
> +MIPS_FEATURE_ISA3 = 0x7, /* MIPS III instruction set architecture */
> +MIPS_FEATURE_ISA4 = 0xF, /* MIPS IV instruction set architecture */
> +MIPS_FEATURE_R4K_EXT = 0x10, /* instruction set extension for MIPS R4K */
Those "extensions" seem to be unimplemented, maybe this was intended to
cover partial support for MIPS32R2, IOW, for a 4KE.
> +MIPS_FEATURE_NEC_EXT = 0x20, /* instruction set extension for NEC CPUs */
This should name the specific CPU core (vr5400 or vr5500?). NEC built
a range of MIPS CPUs (e.g. vr41xx, or R12000) with different capabilities.
[snip]
> +void cpu_mips_set_model(CPUMIPSState *env, uint32_t id)
> +{
> +env->CP0_PRid = id;
> +env->features = 0;
> +switch (id) {
> +case MIPS_R4Kc:
> +set_feature(env, MIPS_FEATURE_ISA3);
> +set_feature(env, MIPS_FEATURE_R4K_EXT);
> +set_feature(env, MIPS_FEATURE_FPU);
> +break;
What's the meaning of "R4Kc" here?
- R4000: We don't have 64bit (ISA III) support.
- 4kc: This one has neither ISA III nor FPU.
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu with kqemu freezes when more than one qemu is running
"Frank J. Beckmann" <[EMAIL PROTECTED]> wrote: > > qemu-0.8.1_1 with kqemu-kmod-1.3.0.p9 on FreeBSD 6.1-RELEASE i386 freezes > after less than one hour runtime when more than one qemu is running. If only > one qemu is running everything works fine. When more than one qemu runs none > of them can use kqemu without freezing after a short time. The frozen qemu > can get killed only by a kill -9. The same happened with kqemu-kmod-1.3.0.p7. > > > The processor is an AMD Athlon 64, but I use the i386 release of FreeBSD. I ran two plan9 guests for over two hours now on my laptop with no crash. They are both doing a ping every 10 ms and continuous floating pt additions. kqemu is enabled but not kernel-kqemu (as plan9performance under kernel-kqemu is abysmal). This is a Pentium M machine with 1GB of memory, running FreeBSD-current. plan9 is not very resource hungry (RSS is about 70MB) so if this is a resource related problem my test won't catch it. A quick reading of kqemu-freebsd.c does not reveal any problems for a uniprocessor machine (but I am not too sure of SMP). Can people who are seeing crashes or hangs provide some more information? - symptom: (host crashes, guest crashes, guest hangs, guest loses its mind) - freebsd version (also if UP or SMP version) - processor - command line used to invoke each qemu instance - what guest oses are run when this happens - if this is triggered more often by specific guest programs - what happens if you run the same guests with less memory. - output of sysctl kern.smp.cpus - VSZ and RSS of these images (from ps axlw). - whether -kernel-kqemu was used I am hoping a pattern will emerge that will help us debug this. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Notes on the QCOW format
Hi, I wrote up some notes on the QCOW format: http://www.gnome.org/~markmc/qcow-image-format.html Perhaps worth including in QEMU itself? Cheers, Mark. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
