Re: [PATCH] mips: pass code of conditional trap

On Fri, 21 Jun 2024, YunQiang Su wrote: > > I haven't touched this stuff for ages, but AFAICT the code is already > > passed where applicable via the environment for `do_tr_or_bp' to handle, > > so I can't understand why your change is needed. > > > > The error_code in env is always zero, as we

Re: [PATCH] mips: pass code of conditional trap

On Fri, 21 Jun 2024, YunQiang Su wrote: > Linux and We use the code of conditional trap instructions to emit > signals other than simple SIGTRAP. Currently, code 6 (overflow), > 7 (div by zero) are supported. It means that if code 7 is used with > a conditional trap instruction, a SIGFPE instead

Re: [PATCH-for-6.1?] target/mips: Remove MOVZ/MOVN opcodes from Loongson 2E

On Mon, 2 Aug 2021, Philippe Mathieu-Daudé wrote: > > At least this trivial program: > > > > int main(void) > > { > > asm volatile(".set push; .set mips4; movn $0,$0,$0; .set pop"); > > return 0; > > } > > > > does not trap on actual hardware. > > Thank you very much for your time and

Re: [PATCH-for-6.1?] target/mips: Remove MOVZ/MOVN opcodes from Loongson 2E

On Mon, 2 Aug 2021, Philippe Mathieu-Daudé wrote: > > Per the "Godson-2E User Manual v0.6", the Loongson 2E processor > > does not implement the MOVZ/MOVN instructions > > I'm confused because I can't find MOVZ/MOVN in the 2E manual and > the 2F explicits the difference. However looking at binuti

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Wed, 17 Mar 2021, Philippe Mathieu-Daudé wrote: > Maciej, I tried your suggestion as follow: > > $ mipsel-linux-gnu-gcc --version > mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0 > Copyright (C) 2018 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. T

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote: > > but your two options to > > choose from are: > > > > 1. Build for the soft-float ABI (`-msoft-float') where any FP calculations > >are compiled such as to be made by the CPU using integer arithmetic. > > With the Debian toolchain I get

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote: > >>> Is there any way we can do this with a distro that isn't Gentoo > >>> so that we can get a container build that is fast enough to be > >>> useful for CI ? > > Using the Debian cross image I get: > > /home/phil/source/qemu/tests/docker/dock

Re: [RFC PATCH 28/42] target/mips/tx79: Move RDHWR usermode kludge to trans_SQ()

On Tue, 16 Feb 2021, Fredrik Noring wrote: > > Not that it's odd (the final address is masked, remember), but that it a > > store > > to an address in the zero page. > > The address always resolves to 0xe83b (then masked) in 32-bit KSEG2, > because rt is always $3 and rd is always $29 so -60

Re: [RFC PATCH 41/42] tests/acceptance: Test R5900 CPU with BusyBox from Sony PS2

On Mon, 15 Feb 2021, Fredrik Noring wrote: > For n32, there's a provisional patch that needs reworking to get merged > (to have libc emulate DMULT etc. rather than the kernel/QEMU).[1] FWIW I think standard `-march=mips3' n32 Linux binaries need to work with the R5900, and therefore the kernel

Re: [PATCH-for-5.2?] target/mips/translate: Check R6 reserved encoding for Load Linked Word

On Tue, 8 Dec 2020, Philippe Mathieu-Daudé wrote: > Duh I hit that again, read the patch again, looks correct. I guess > I got confused myself reviewing the offending patch... > So I'm applying this patch to mips-next queue, using > Fixes: d9224450208 ("target-mips: Tighten ISA level checks") Wh

Re: [PATCH 3/4] default-configs: Support o32 ABI with 64-bit MIPS CPUs

On Thu, 19 Nov 2020, Philippe Mathieu-Daudé wrote: > MIPS o32 ABI on 64-bit CPUs looks like a ILP32-on-64bit data > model, allowing 64-bit arithmetic and data movement instructions. > > This is the default ABI used by the "Sony Linux Toolkit for > Playstation 2". Please don't, not at least with

Re: [Qemu-devel] [RFC PATCH 0/2] docker: Add gentoo-mipsr5900el-cross image

On Mon, 19 Nov 2018, Fredrik Noring wrote: > > The first patch adds a cross toolchain for the R5900 MIPS. > > It is working correctly but the patches provided by Fredrik in [1] don't > > have proper S-o-b, thus it is tagged RFC. > > Fredrik: any update on the status of those patches upstream? > >

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Maciej W. Rozycki wrote: > > Some readelf results: > > > > mips64el/stretch > > > > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > > Class: ELF64 > > Flags: 0x8007, noreorder, pic, cpic, mips64r2 > &g

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > > > in a separate patch - there is no document to support their inclusion. > > > > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could > > your al

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Laurent Vivier wrote: > > I believe MIPS64 Debian is all n32. > > Some readelf results: > > mips64el/stretch > > Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Flags: 0x8007, noreorder, pic, cpic, mips64r2 Hmm, that's weird -- what

Re: [Qemu-devel] [PATCH 0/2] linux-user/mips: Support the n32 ABI for the R5900

On Fri, 9 Nov 2018, Laurent Vivier wrote: > if you have time, o32 & n32 support needs to be reworked. > > We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF > mask/magic. > > As n32 identifies a kernel ABI version, we should have only one binary > for qemu-mips and qemu-mipsn32

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > ... and DMULT, DMULTU, DDIV and DDIVU > > are part of the MIPS III ISA. They are emulated in user mode to support > > generic MIPS III programs. > > Pure MIPS III executables should not be a concern of the R5900 > emulation, but R5900 executable

Re: [Qemu-devel] [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes

On Thu, 8 Nov 2018, Fredrik Noring wrote: > > Fredrik, do you know by any chance if a document exists that would justify > > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by > > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? > > > > I think gcc f

Re: [Qemu-devel] [PATCH 1/2] target/mips: Fix decoding mechanism of R5900 MFLO1, MFHI1, MTLO1 and MTHI1

On Mon, 5 Nov 2018, Fredrik Noring wrote: > where ac can range from 0 to 3. Do you have a link to a better reference, > by chance, that isn't tied to microMIPS? Here: you'll find everything you need I believe. HTH, Maciej

Re: [Qemu-devel] [PATCH 1/2] target/mips: Fix decoding mechanism of R5900 MFLO1, MFHI1, MTLO1 and MTHI1

On Sun, 4 Nov 2018, Fredrik Noring wrote: > It appears the correct function is tcg_gen_mov_tl because the TX79 manual > says > > MFHI: GPR[rd]63..0 <- HI63..0 > MFLO: GPR[rd]63..0 <- LO63..0 > MTHI: HI63..0 <- GPR[rs]63..0 > MTLO: LO63..0 <- GPR[rs]63..0 > MFHI1:

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Mon, 29 Oct 2018, Aleksandar Markovic wrote: > > > Without TARGET_MIPS64, we can't say we emulate R5900 - we are emulating > > > some other CPU that never existed. > > > > > > Convince me that I am wrong. > > > > R5900 O32 is usable. > > Absolutely not. This kind of emulation infidelity can't

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Sun, 28 Oct 2018, Aleksandar Markovic wrote: > I truly need your help here. As you can conclude from the discussion, > R5900 folks (anybody correct me if I am wrong) have some problems using > any ABI other than O32. The maximum the R5900 can support is the n32 ABI, owing to 32-bit virtual

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

On Fri, 26 Oct 2018, Richard Henderson wrote: > > Overall this source file is clearly a modified copy of an ancient version > > of the opcode table included with the opcodes library from binutils and I > > think it would benefit from a refresh. > > You can't do that because of GPL v3, sadly.

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > NB all but pipeline 1 instructions of these are also implemented by other > > members of the TXx9 family. They seem to be referred to as just "multiply > > and multiply-add instructions" in the TX79 manual (cf Section B.3.1). > > Would > > ASE_TOSHIBA_MMI -- TX79 128-bit mul

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > > Option 3: Extend the mips_opcode::membership field. > > > > It's trivial to extend the field to uint64_t. > > Is the membership field intended to be used? The opcodes for CLZ and CLO > clash with the R5900 opcodes for MADD1 and MADDU1, resulting in incorrect > disassembly of MA

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Fredrik, > > target/mips/translate.c:4888:38: error: passing argument 3 of > > ‘tcg_gen_add2_i32’ from incompatible pointer type > > [-Werror=incompatible-pointer-types] > > tcg_gen_add2_i32(t2, t3, cpu_LO[acc], cpu_HI[acc], t2, t3); > > ^~

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

On Mon, 22 Oct 2018, Maciej W. Rozycki wrote: > Hi Maciej, What an odd copy & paste thinko! I can't believe I addressed myself in the opening of my e-mail. :) Maciej

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900

Hi Maciej, > > I added ASE_MMI flag along with INSN_R5900, I think this fits better in > > the overall MIPS for QEMU design. > > Maciej -- can we add "MMI" under "ASEs implemented" in the kernel too, > even if it is a vendor-specific architecture extension that normally > isn't counted as an ASE?

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

Hi Fredrik, > > The C790 is a follow-up to the R5900. The R5900 has an FPU that is not > > compliant to the IEEE 754 standard for floating-point arithmetic. It > > doesn't implement exceptions, infinities, NaNs or denormals. It doesn't > > implement the the double format either, but that is

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Tue, 16 Oct 2018, Fredrik Noring wrote: > > I would not implement r5900 for mips32 in that case, > > I would implement it only for TARGET_MIPS64. > > R5900 Linux implements the O32 ABI, which is why 32-bit QEMU user-mode is > very useful. Perhaps a better alternative is to define the MMI regis

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Tue, 16 Oct 2018, Fredrik Noring wrote: > One option is to create a new array such as > > static TCGv_i64 mmi_gpr[32]; > > that represents the upper 64 bits of each GPR. Then cpu_gpr must be of > a 64-bit type too, even when QEMU runs in 32-bit user mode. The R5900 > does not implement CP0.St

Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU

On Sun, 14 Oct 2018, Philippe Mathieu-Daudé wrote: > > > +gen_move_low32(cpu_LO[acc], t2); > > > +gen_move_high32(cpu_HI[acc], t2); > > > +if (rd) { > > > +gen_move_low32(cpu_gpr[rd], t2); > > > > As above, are LO, HI and GPR[rd] sign-extended to

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > > TX79 do not implement DMULT or DMULTU, the Tx49 does and they do support > > the extra `rd' operand there[1]. Still no DMADD or DMADDU though. > > As does the TX39. Umm, the TX39 is 32-bit and does not have 64-bit instructions, so it can

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > >> I'd use: > >> > >>MIPS_INVAL("mul/div Toshiba"); > > > > But just like `gen_mul_vr54xx' this function doesn't handle division! > > Per the commit message, I understood this function would eventually > handle "the R5900 specific

Re: [Qemu-devel] [PATCH v6 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

On Sun, 30 Sep 2018, Philippe Mathieu-Daudé wrote: > > +MIPS_INVAL("mul R5900"); > > I'd use: > >MIPS_INVAL("mul/div Toshiba"); But just like `gen_mul_vr54xx' this function doesn't handle division! > > @@ -22378,6 +22449,8 @@ static void decode_opc_special_legacy(CPUMIPSSt

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Fri, 28 Sep 2018, Philippe Mathieu-Daudé wrote: > > What's wrong with `gen_mul_r5900' anyway? > > I plan to use this function (adding MADD/MADDU) for R3900 based cores > (which don't seemt related to Emotion Engine). Fair enough. I reached for documentation and these instructions seem to

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Fri, 28 Sep 2018, Philippe Mathieu-Daudé wrote: > > > Note, these instructions are also valid on the R3900 (which also has > > > MADD/MADDU). > > > > > > Would gen_mul_toshiba() be a better common name? I don't like it but > > > can't think of another. > > > > I propose gen_mul_3op, since its d

Re: [Qemu-devel] [PATCH v5 2/8] target/mips: Support R5900 specific three-operand MULT and MULTU

On Thu, 27 Sep 2018, Philippe Mathieu-Daudé wrote: > > +static void gen_mul_r5900(DisasContext *ctx, uint32_t opc, > > + int acc, int rd, int rs, int rt) > > Since we have acc = 0 we can directly use cpu_LO[0] and cpu_HI[0], > removing needs for an 'acc' argument. Corre

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

On Tue, 25 Sep 2018, Philippe Mathieu-Daudé wrote: > >From the DS: > > The C790 core has the following features: > - Large on-chip caches > • Instruction cache: 32KB, 2-way set associative > • Data cache: 32KB, 2-way set-associative (with write-back proto

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

On Mon, 24 Sep 2018, Philippe Mathieu-Daudé wrote: > >> >From the DS: > >> > >> The C790 core has the following features: > >>- Large on-chip caches > >> • Instruction cache: 32KB, 2-way set associative > >> • Data cache: 32KB, 2-way set-associative (with write-back protocol) > >> >

Re: [Qemu-devel] [PATCH v5 0/8] target/mips: Support R5900 GCC programs in user mode

On Sun, 23 Sep 2018, Fredrik Noring wrote: > > Patch 4 will break bisect on clang builds. The reason for this is that > > clang treats unused functions as errors. Therefore, patch 4 must be merged > > with some of subsequent patches that contain first invocation of the > > function currently defin

Re: [Qemu-devel] [PATCH v5 6/8] target/mips: Define the R5900 CPU

Hi Philippe, > > diff --git a/target/mips/translate_init.inc.c > > b/target/mips/translate_init.inc.c > > index b3320b9dc7..71fd83de06 100644 > > --- a/target/mips/translate_init.inc.c > > +++ b/target/mips/translate_init.inc.c > > @@ -410,6 +410,53 @@ const mips_def_t mips_defs[] = > >

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Fredrik, > I agree, that is important too. I will post an updated v5 soon. Another > alternative change is to define check_insn_opc_user_only as > > static inline void check_insn_opc_user_only(DisasContext *ctx, int flags) > { > #ifndef CONFIG_USER_ONLY > check_insn_opc_removed(ctx, flags)

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Fredrik, Nitpicking here, but I think it's what makes code clean and pleasant to read. On Sun, 16 Sep 2018, Fredrik Noring wrote: > diff --git a/target/mips/translate.c b/target/mips/translate.c > index 77d678353e..327e96307b 100644 > --- a/target/mips/translate.c > +++ b/target/mips/transl

Re: [Qemu-devel] [PATCH v3] target/mips: Support R5900 GCC programs in user mode

Hi Fredrik, > Many thanks for your review, Maciej, You are welcome! > > Eventually you'll have to remove all these instructions (plus LL and SC) > > from the system emulation mode. In fact I think it would make sense to do > > that right away, because I believe it will be a reasonably simpl

Re: [Qemu-devel] [PATCH v2] target/mips: Initial support for MIPS R5900

Hi Fredrik, > Aleksandar, Aurelien, Maciej -- are you happy with this initial v2 patch? I have been more thorough on this occasion, and I do hope I have caught everything. See the notes below, in addition to what the others wrote. Please apply to v3 accordingly; I started writing this befo

Re: [Qemu-devel] [PATCH v2] target/mips: Initial support for MIPS R5900

Hi Fredrik, > Aleksandar, Aurelien, Maciej -- are you happy with this initial v2 patch? I have skimmed over and I have a couple of comments. I'll try to finalise them ASAP, however I'm currently at the GNU Tools Cauldron and much of my time is taken by the event. Maciej

Re: [Qemu-devel] [RFC] target/mips: Initial support for MIPS R5900

On Sat, 7 Jul 2018, Fredrik Noring wrote: > The MIPS R5900 is normally taken to be MIPS3, but it has MOVN, MOVZ and PREF > defined in MIPS4 which is why ISA_MIPS4 is chosen for this patch. It also has several instructions removed, so I don't think you can really just mark it MIPS IV without spe

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of ..

On Mon, 20 Jun 2016, Aleksandar Markovic wrote: > This patch is about NaN-2008 flavor of Mips instructions CEIL, CVT, > FLOOR, ROUND, TRUNC only (its title is "Add nan2008 flavor..."). > > Legacy-NaN flavors of the same Mips instructions already operate > correctly, and there is nothing to be f

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of ..

On Tue, 14 Jun 2016, Leon Alrae wrote: > > 1. A bug fix for SoftFloat legacy-NaN (original) MIPS support, which has > >been there probably since forever (i.e. since the MIPS target was added > >to QEMU). > > I've just done another round of review and as far as I can tell these > patches

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of ..

On Fri, 10 Jun 2016, Aleksandar Markovic wrote: > The changes that make QEMU behavior the same as hardware behavior (in > relation to CEIL, CVT, FLOOR, ROUND, TRUNC Mips instructions) are > already contained in this patch. Good, however that means that you've really combined two logically sep

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of ..

On Fri, 10 Jun 2016, Aleksandar Markovic wrote: > I referred to SoftFloat library in QEMU code, and the case "Operand is > smaller than INT_MIN" is different between SoftFloat and Mips-B, while > the case "Operand is a NaN" is different between SoftFloat and Mips-A. Ah, but then you just can a

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Wed, 8 Jun 2016, Eric Blake wrote: > > Unlike `..` the $(..) Bourne shell construct is not fully portable, some > > implementations do not recognise it. > > All POSIX implementations support it. The only shell that doesn't is > from Solaris /bin/sh, and that pre-dates modern OpenSolaris whic

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Wed, 8 Jun 2016, Stefan Weil wrote: > > Unlike `..` the $(..) Bourne shell construct is not fully portable, some > > implementations do not recognise it. Consequently this change potentially > > breaks building QEMU on some systems, possibly in a non-obvious way, as > > there's no explicit

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

On Mon, 16 May 2016, Stefan Weil wrote: > This fixes these warnings from shellcheck: > > ^-- SC2006: Use $(..) instead of deprecated `..` > > Signed-off-by: Stefan Weil > --- > > More warnings from shellcheck for configure and other files > will be handled by later patches. Unlike `..` t

Re: [Qemu-devel] [PATCH v6 8/9] target-mips: Add nan2008 flavor of ..

On Mon, 16 May 2016, Aleksandar Markovic wrote: > Here one can distinguish three cases: > > CASE MIPS-A: (FCR31.NAN2008 == 1) > >1. Operand is a NaN, result should be 0; >2. Operand is larger than INT_MAX, result should be INT_MAX; >2. Operand is smaller than INT_MIN, result should b

Re: [Qemu-devel] [PATCH v5 7/9] target-mips: Add nan2008 flavor of ..

On Wed, 4 May 2016, Aleksandar Markovic wrote: > > > @@ -8919,7 +8920,11 @@ static void gen_farith (DisasContext *ctx, enum > > > fopcode op1, > > > TCGv_i64 fp64 = tcg_temp_new_i64(); > > > > > > gen_load_fpr32(ctx, fp32, fs); > > > -gen_helper_float_roundl_

Re: [Qemu-devel] [PATCH v5 5/9] target-mips: Activate IEEE 274-2008 signaling NaN bit meaning

On Mon, 25 Apr 2016, Aleksandar Markovic wrote: > No, nothing is lost. The plan is to add this functionality at a later time. OK then, as you prefer. Although I find the order somewhat odd as r5+ is a special case of r3. Maciej

Re: [Qemu-devel] [PATCH v5 5/9] target-mips: Activate IEEE 274-2008 signaling NaN bit meaning

On Mon, 18 Apr 2016, Aleksandar Markovic wrote: > Functions mips_cpu_reset() and msa_reset() are updated so that flag > snan_bit_is_one is properly set for any Mips FPU/MSA configuration. > For main FPUs, CPUs with FCR31's FCR31_NAN2008 bit set will invoke > set_snan_bit_is_one(0). For MSA, as it

Re: [Qemu-devel] [PATCH 0/2] target-mips: Initiate IEEE 754-2008 support for Mips

On Thu, 7 Apr 2016, Aleksandar Markovic wrote: > This patch series is based on the original set of patches proposed by Maciej > Rozycki: http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg00968.html Please try and spell out my name in full, thank you. Maciej

Re: [Qemu-devel] Memory mapping on MIPS

On Mon, 22 Feb 2016, Igor R wrote: > What should happen if I map KSEG2 directly as a continuation of KSEG1, > i.e. substitute TLB lookup with "address - (int32_t)KSEG1_BASE"? Guest > Linux seems to work correctly (but maybe it's just a matter of luck?). The 32-bit MIPS port of Linux uses KSEG2 f

Re: [Qemu-devel] [PATCH 14/15] tcg-mips: Use mipsr6 instructions in branches

On Tue, 9 Feb 2016, Richard Henderson wrote: > > So to be correct + efficient, it should only put the nop in if the next > > generated instruction is a CTI. I imagine that would be a bit messy / > > fragile, but maybe doable? I haven't looked too deeply. > > Ouch, I didn't notice this about these

Re: [Qemu-devel] [PATCH] target-mips: silence NaNs for cvt.s.d and cvt.d.s

On Sun, 6 Dec 2015, Aurelien Jarno wrote: > cvt.s.d and cvt.d.s are FP operations and thus need to convert input > sNaN into corresponding qNaN. Explicitely use the floatXX_maybe_silence_nan > functions for that as the floatXX_to_floatXX functions do not do that. > > Cc: Leon Alrae > Signed-off-

Re: [Qemu-devel] [PATCH v2] target-mips: remove wrong checks for recip.fmt and rsqrt.fmt

On Mon, 19 Oct 2015, Leon Alrae wrote: > >> Instructions recip.{s|d} and rsqrt.{s|d} do not require 64-bit FPU neither > >> they require any particular mode for its FPU. This patch removes the checks > >> that may break a program that uses these instructions. > > > > That is correct. That said th

Re: [Qemu-devel] [PATCH pic32 v2 4/5] Two new processor variants: M4K and microAptivP.

On Wed, 1 Jul 2015, Aurelien Jarno wrote: > > diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c > > index ddfaff8..430a547 100644 > > --- a/target-mips/translate_init.c > > +++ b/target-mips/translate_init.c > > @@ -232,6 +232,52 @@ static const mips_def_t mips_defs[] = > >

Re: [Qemu-devel] [PATCH pic32 v2 2/5] Fixed random index generation for TLBWR instruction. It was not quite random and did not skip Wired entries.

On Wed, 1 Jul 2015, Aurelien Jarno wrote: > Secondly, I don't think calling random() is the correct thing to do. > It's an expensive function that is not thread safe. Quoting the > specification: > > "Within the required constraints of the upper and lower bounds, the > manner in which the pro

Re: [Qemu-devel] [PATCH] target-mips: add ERETNC instruction and Config5.LLB bit

On Fri, 5 Jun 2015, Leon Alrae wrote: > > As a side note, I have seen that you have added a check for MIPS2 to the > > ERET instruction. This is correct, but given in practice we don't > > emulate any MIPS1 CPU, I do wonder if it's not the time to make MIPS2 > > the basic instruction set and remov

Re: [Qemu-devel] [PATCH v3 2/2] semihosting: add --semihosting-config arg sub-argument

On Thu, 21 May 2015, Liviu Ionescu wrote: > p.s. and I think there are major differences between using -append to > pass arguments to the kernel and passing arguments to semihosting, this > being one of the reasons for suggesting a new command. Out of curiosity, why do you think there are diff

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Thu, 14 May 2015, Leon Alrae wrote: > > I don't think we have. The specification is a bit unclear I must admit > > and it also defines the details of vector load and store operations as > > implementation dependent, so there's no further clarification. > > This is specified in "MIPS Archit

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Richard Henderson wrote: > >> I believe the problem is that MSA vector register's size is 16-bytes > >> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store > >> is supposed to be atomic. > > > > Not really AFAICT. Here's what the specification says[1]: >

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Leon Alrae wrote: > > Certainly we do. It's all in softmmu_template.h. > > I believe the problem is that MSA vector register's size is 16-bytes > (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store > is supposed to be atomic. Not really AFAICT. Here's

Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA

On Wed, 13 May 2015, Richard Henderson wrote: > > +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env, > > + target_ulong addr, > > + int rw, > > +

Re: [Qemu-devel] [PATCH 2/3] ppc64-softmmu: Remove unsupported FDC from config

On Wed, 11 Mar 2015, Alexander Graf wrote: > > So if you know how to get working floppy disk with qemu-system-ppc64, > > that would help me a lot in rejecting requests from libvirt folks :) > > Thanks :) > > I don't think you want floppy disk emulation on -M pseries at all. In > fact, you only ev

Re: [Qemu-devel] mfocrf missing on e500v2

On Fri, 6 Mar 2015, Alexander Graf wrote: > >> And lo and behold, I really couldn't find any reference to mfocrf in the > >> e500v2 spec. > > > > Do real e500 processors trap on this operation as well? > > The illegal instruction I posted about above was when running qemu > *on* e500v2, becau

Re: [Qemu-devel] mfocrf missing on e500v2

On Fri, 6 Mar 2015, Alexander Graf wrote: > I've finally managed to check out why my e500v2 automated tests fail to > run. Apparently they break because autotest wants to execute target code > and runs into an illegal instruction while doing that: > > Program received signal SIGILL, Illegal instr

Re: [Qemu-devel] [PATCH 2/2] target-mips: add missing MSA and correct FP in VMState

On Thu, 19 Feb 2015, Leon Alrae wrote: > > Surely these fp_status fields are simply implementation of the architectural > > CSR registers? > > > > IMO you shouldn't store things related to TCG state, but always how the > > architecture represents it. That way you're free to change the TCG > > im

Re: [Qemu-devel] [PATCH] target-mips: fix CP0.BadVAddr by stopping translation on Address error

On Thu, 19 Feb 2015, Leon Alrae wrote: > > I think this deserves a better description as it is about the specific > > case of an unaligned standard MIPS instruction fetch. Address Error > > exceptions can also happen for other reasons: unaligned data accesses or > > any accesses outside memor

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Tue, 9 Dec 2014, Maciej W. Rozycki wrote: > Index: qemu-git-trunk/target-mips/op_helper.c > === > --- qemu-git-trunk.orig/target-mips/op_helper.c 2014-12-08 > 23:22:12.0 + > +++ qemu-git-tr

Re: [Qemu-devel] [PULL 06/37] target-ppc: VXSQRT Should Not Be Set for NaNs

On Wed, 7 Jan 2015, Alexander Graf wrote: > diff --git a/target-ppc/fpu_helper.c b/target-ppc/fpu_helper.c > index 7f74466..81db60f 100644 > --- a/target-ppc/fpu_helper.c > +++ b/target-ppc/fpu_helper.c > @@ -920,14 +923,16 @@ uint64_t helper_fsqrt(CPUPPCState *env, uint64_t arg) > > farg.l

Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

On Mon, 9 Feb 2015, Peter Maydell wrote: > >> I'm not sure if it's a good idea to change the meaning of linux-user > >> qemu-mips64 and qemu-mips64el, this will cause unnecessary confusion in > >> my opinion. I think we’d be better off leaving it consistent across QEMU > >> versions. > > > > Well

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Tue, 10 Feb 2015, Leon Alrae wrote: > > These cases could be addressed by either replacing subtraction from 0.0 > > with multiplication by -1.0, or by tweaking the rounding mode as needed > > temporarily. Given that the computational cost of multiplication is > > uncertain and likely highe

Re: [Qemu-devel] [PATCH 7/7] target-mips: Add IEEE 754-2008 features support

On Mon, 9 Feb 2015, Leon Alrae wrote: > > +if (info->elf_flags & EF_MIPS_NAN2008) > > +env->active_fpu.fcr31 |= > > +(1 << FCR31_NAN2008) & env->active_fpu.fcr31_rw_bitmask; > > +else > > +env->active_fpu.fcr31 &= > > +~((1 <<

Re: [Qemu-devel] [PATCH v2 1/2] target-mips: Rework ABIs to allow all required configurations

On Mon, 9 Feb 2015, Leon Alrae wrote: > > Rework the MIPS ABIs and CPU emulations available according to the > > following target list: > > > > - mips|mipsel -- 32-bit CPUs only, system and user emulation mode, > >o32 user ABI, > > > > - mips64|mips64el -- 32-bi

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

On Fri, 6 Feb 2015, Maciej W. Rozycki wrote: > > >> I think this means that: > > >> (1) we want to put handling of silencing the signaling NaNs > > >> into the NaN conversion functions themselves (since it's > > >> too late to do it corre

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

On Fri, 6 Feb 2015, Peter Maydell wrote: > > What I think would make sense here is instead of say `float32_to_float64' > > making a call to `float64_maybe_silence_nan' directly, we'd have a static > > inline function or a macro called say `float64_convert_silence_nan' > > invoked where the former

Re: [Qemu-devel] [PATCH 1/7] softfloat: Fix sNaN handling in FP conversion operations

formats. > > > > Therefore quieten any sNaN encountered in floating-point format > > conversions, in the usual manner. > > > > References: > > > > [1] "IEEE Standard for Floating-Point Arithmetic", IEEE Computer > > Society, IEEE Std

Re: [Qemu-devel] [PATCH v2 6/7] softfloat: Add SoftFloat status `nan2008_mode' flag

On Thu, 5 Feb 2015, Peter Maydell wrote: > > Index: qemu-git-trunk/fpu/softfloat-specialize.h > > === > > --- qemu-git-trunk.orig/fpu/softfloat-specialize.h 2014-12-11 > > 22:42:41.128934304 + > > +++ qemu-git-trunk/fpu/soft

Re: [Qemu-devel] [PATCH 0/7] MIPS: IEEE 754-2008 features support

On Tue, 3 Feb 2015, Thomas Schwinge wrote: > > I think Thomas, being the writer of the majority of code comprising these > > patches > > Too bad that Git doesn't allow for listing several authors. ;-) I believe `Signed-off-by' serves this purpose: "The Signed-off-by: tag indicates that the

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Sat, 31 Jan 2015, Peter Maydell wrote: > >> > Hmm, so perhaps my idea for a later improvement: > >> > > >> >> Eventually we might want to move the new inline functions into a > >> >> separate header to be included from softfloat.h instead of softfloat.c, > >> >> but let's make changes one ste

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Fri, 30 Jan 2015, Peter Maydell wrote: > > Hmm, so perhaps my idea for a later improvement: > > > >> Eventually we might want to move the new inline functions into a > >> separate header to be included from softfloat.h instead of softfloat.c, > >> but let's make changes one step at a time. >

Re: [Qemu-devel] [PATCH v2 3/7] softfloat: Convert `*_default_nan' variables into inline functions

On Fri, 30 Jan 2015, Leon Alrae wrote: > > @@ -760,6 +760,6 @@ static inline int float128_is_any_nan(fl > > > > /* > > | The pattern for a default generated quadruple-precision NaN. > > > > *--

Re: [Qemu-devel] [PATCH 0/7] MIPS: IEEE 754-2008 features support

On Fri, 30 Jan 2015, Peter Maydell wrote: > > This patch series comprises changes to QEMU, both the MIPS backend and > > generic SoftFloat support code, to support IEEE 754-2008 features > > introduced to revision 3.50 of the MIPS Architecture as follows. > > Just to let you know that: > (1) the

Re: [Qemu-devel] [PATCH] target-mips: use CP0EnLo_XI instead of magic number

On Thu, 29 Jan 2015, Leon Alrae wrote: > > And do we want to have CP0C3_LPA set in the few templates that do in the > > first place? AFAICT we don't really implement LPA so this bit will > > confuse software. Of course implementing it would be another option, not > > very complicated AFAICS,

Re: [Qemu-devel] [PATCH] target-mips: use CP0EnLo_XI instead of magic number

On Mon, 26 Jan 2015, Leon Alrae wrote: > Signed-off-by: Leon Alrae > --- Enthusiastically: Reviewed-by: Maciej W. Rozycki However... > diff --git a/target-mips/translate.c b/target-mips/translate.c > index 635192c..77d89be 100644 > --- a/target-mips/translate.c >

Re: [Qemu-devel] [PATCH] target-mips: fix CP0.BadVAddr by stopping translation on Address error

On Mon, 26 Jan 2015, Leon Alrae wrote: > BadVAddr is supposed to capture the most recent address that caused > the exception. Currently this is not happening as translation is not stopped > and BadVAddr is updated with subsequent addresses. > > Signed-off-by: Leon Alrae > --- I think this dese

Re: [Qemu-devel] [PATCH] target-mips: ll and lld cause AdEL exception for unaligned address

On Mon, 26 Jan 2015, Leon Alrae wrote: > Signed-off-by: Leon Alrae > --- Reviewed-by: Maciej W. Rozycki Maciej

Re: [Qemu-devel] [PATCH] target-mips: fix detection of the end of the page during translation

I'm not sure if you need this, but just in case it helps anyhow. Reviewed-by: Maciej W. Rozycki > diff --git a/target-mips/translate.c b/target-mips/translate.c > index e9d86b2..f33c10c 100644 > --- a/target-mips/translate.c > +++ b/target-mips/translate.c > @@ -19103,6 +

Re: [Qemu-devel] Qemu with GDB - Query

On Sat, 24 Jan 2015, manish tiwari wrote: > I am new to QEMU and trying to attach gdb with qemu on powepc host. > > I have tried below options > > qemu-system-ppc -enable-kvm -nographic -m 512 -M ppce500 -cpu e500mc -gdb > tcp::1234 -s -S -kernel uImage -initrd rootfs.ext2.gz -append > "root=/de

Re: [Qemu-devel] [PATCH] target-mips: Clean up switch fall through after commit fecd264

On Tue, 20 Jan 2015, Peter Maydell wrote: > In this particular case, this part of the file is fine and the > problem is simply that this patch as it stands introduces a single > line (the one above) that's not indented correctly. The only fix > required is to delete one space in the line added by

Re: [Qemu-devel] [PATCH] target-mips: Clean up switch fall through after commit fecd264

On Tue, 20 Jan 2015, Markus Armbruster wrote: > >> diff --git a/target-mips/translate.c b/target-mips/translate.c > >> index e9d86b2..8abc12b 100644 > >> --- a/target-mips/translate.c > >> +++ b/target-mips/translate.c > >> @@ -18729,6 +18729,7 @@ static void decode_opc(CPUMIPSState *env, > >> Di

  1   2   3   >