Test steps:
(qemu) device_add e1000,addr=adsf
Property 'e1000.addr' doesn't take value 'adsf'
(qemu) info qtree
Then qemu crashed.
When it fails to set properties, qdev's parent is already set, but the
object hasn't been added to parent object, object_unparent() won't
unparent the device. Th
On Tue, Dec 31, 2013 at 04:06:57PM +0800, Amos Kong wrote:
> Test steps:
> (qemu) device_add e1000,addr=adsf
> Property 'e1000.addr' doesn't take value 'adsf'
> (qemu) info qtree
> Then qemu crashed.
>
> When it fails to set properties, qdev's parent is already set, but the
> object hasn't b
On Tue, Dec 31, 2013 at 05:09:36PM +0800, Hu Tao wrote:
> On Tue, Dec 31, 2013 at 04:06:57PM +0800, Amos Kong wrote:
> > Test steps:
> > (qemu) device_add e1000,addr=adsf
> > Property 'e1000.addr' doesn't take value 'adsf'
> > (qemu) info qtree
> > Then qemu crashed.
> >
> > When it fails to
Signed-off-by: Kewei Yu
---
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 7511e70..92dafa5 100644
--- a/vl.c
+++ b/vl.c
@@ -2922,7 +2922,7 @@ int main(int argc, char **argv, char **envp)
bdrv_init_with_whitelist();
-autostart= 1;
+
On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
> When we disabling vnc from "./configure", the qemu can't use the vnc option.
"disable", -"the", "QEMU",
> So qtest can't use the "vnc -none ", otherwise "make check" will hang.
>
Curious, why exactly does make check hang? Shouldn't it just fail
2013/12/31 Peter Crosthwaite
> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
> > When we disabling vnc from "./configure", the qemu can't use the vnc
> option.
>
> "disable", -"the", "QEMU",
>
Do you mean "s/disabling/disable; s/the\ qemu/QEMU"?
>
> > So qtest can't use the "vnc -none ", oth
This patchset completes the FP emulation, leaving us with only
Neon (and CRC32) to go to complete the user-mode emulation.
Most of this is fixing issues and adding new features to softfloat.
(As usual, all Linaro authored softfloat patches are licensed under
either softfloat-2a or softfloat-2b, at
From: Alexander Graf
This patch adds emulation for the instruction group labeled
"Floating-point <-> fixed-point conversions" in the ARM ARM.
Namely this includes the instructions SCVTF, UCVTF, FCVTZS, FCVTZU
(scalar, fixed-point).
Signed-off-by: Alexander Graf
[WN: Commit message tweak, rebas
Add the float to 16 bit integer conversion routines. These can be
trivially implemented in terms of the int32_to_float* routines, but
providing them makes our API more symmetrical and can simplify callers.
Signed-off-by: Peter Maydell
---
include/fpu/softfloat.h | 17 +
1 file ch
From: Tom Musta
This patch adds the float32_to_uint64() routine, which converts a
32-bit floating point number to an unsigned 64 bit number.
This contribution can be licensed under either the softfloat-2a or -2b
license.
V2: Reduced patch to just this single routine per feedback from Peter
Mayd
Tidy up the get/set accessors for the fp state to add missing ones
and make them all inline in softfloat.h rather than some inline and
some not.
Signed-off-by: Peter Maydell
---
The specific one we want for A64 is to get the rounding mode,
but we might as well fill in the gaps.
---
fpu/softfloat
We implement a number of float-to-integer conversions using conversion
to an integer type with a wider range and then a check against the
narrower range we are actually converting to. If we find the result to
be out of range we correctly raise the Invalid exception, but we must
also suppress other
From: Will Newton
Make the VFP_CONV_FIX helpers a little more flexible in
preparation for the A64 uses. This requires two changes:
* use the correct softfloat conversion function based on itype
rather than always the int32 one; this is possible now that
softfloat provides int16 versions an
From: Tom Musta
The float64_to_uint64_round_to_zero routine is incorrect.
For example, the following test pattern:
46697351FF4AEC29 / 0x1.97351ff4aec29p+103
currently produces 8000 instead of .
This patch re-implements the routine to temporarily force the
round
From: Will Newton
Define the full set of floating point to fixed point conversion
helpers required to support AArch64.
Signed-off-by: Will Newton
Signed-off-by: Peter Maydell
---
target-arm/helper.c | 11 ++-
target-arm/helper.h | 16
2 files changed, 26 insertions(+)
From: Will Newton
The VFP conversion helpers for A32 round to zero as this is the only
rounding mode supported. Rename these helpers to make it clear that
they round to zero and are not suitable for use in the AArch64 code.
Signed-off-by: Will Newton
Signed-off-by: Peter Maydell
---
target-ar
Add the conversion functions float16_to_float64() and
float64_to_float16(), which will be needed for the ARM
A64 instruction set.
Signed-off-by: Peter Maydell
---
fpu/softfloat.c | 75 +
include/fpu/softfloat.h | 2 ++
2 files changed, 77
From: Will Newton
Add support for the AArch64 floating-point <-> integer conversion
instructions to disas_fpintconv. In the process we can rearrange
and simplify the detection of unallocated encodings a little.
We also correct a typo in the instruction encoding diagram for this
instruction group:
From: Tom Musta
The comment preceding the float64_to_uint64 routine suggests that
the implementation is broken. And this is, indeed, the case.
This patch properly implements the conversion of a 64-bit floating
point number to an unsigned, 64 bit integer.
This contribution can be licensed under
Our float32 to float16 conversion routine was generating the correct
numerical answers, but not always setting the right set of exception
flags. Fix this, mostly by rearranging the code to more closely
resemble RoundAndPackFloat*, and in particular:
* non-IEEE halfprec always raises Invalid for in
From: Tom Musta
The float64_to_uint32_round_to_zero routine is incorrect.
For example, the following test pattern:
425F81378DC0CD1F / 0x1.f81378dc0cd1fp+38
will erroneously set the inexact flag.
This patch re-implements the routine to use the float64_to_uint64_round_to_zero
routine. If s
IEEE754-2008 specifies a new rounding mode:
"roundTiesToAway: the floating-point number nearest to the infinitely
precise result shall be delivered; if the two nearest floating-point
numbers bracketing an unrepresentable infinitely precise result are
equally near, the one with larger magnitude sha
From: Will Newton
ARMv8 requires support for converting 32 and 64bit floating point
values to signed and unsigned 16bit integers.
Signed-off-by: Will Newton
[PMM: updated not to incorrectly set Inexact for Invalid inputs]
Signed-off-by: Peter Maydell
---
fpu/softfloat.c | 80 +
If the input to float*_scalbn() is denormal then it represents
a number 0.[mantissabits] * 2^(1-exponentbias) (and the actual
exponent field is all zeroes). This means that when we convert
it to our unpacked encoding the unpacked exponent must be one
greater than for a normal number, which represen
Add support for FCVT between half, single and double precision.
Signed-off-by: Peter Maydell
---
target-arm/helper.c| 20 +
target-arm/helper.h| 2 ++
target-arm/translate-a64.c | 75 +-
3 files changed, 96 insertions(+), 1
The VFP fixed point conversion helpers first call float_scalbn and
then convert the result to an integer. This scalbn operation may
set floating point exception flags for:
* overflow & inexact (if it overflows to infinity)
* input denormal squashed to zero
* output denormal squashed to zero
Of t
From: Tom Musta
The float64_to_uint32 has several flaws:
- for numbers between 2**32 and 2**64, the inexact exception flag
may get incorrectly set. In this case, only the invalid flag
should be set.
test pattern: 425F81378DC0CD1F / 0x1.f81378dc0cd1fp+38
- for numbers between 2*
This patch adds support for those instructions in the "Floating-point
data-processing (1 source)" group which are simple 32-bit-to-32-bit
or 64-bit-to-64-bit operations (ie everything except FCVT between
single/double/half precision).
We put the new round-to-int helpers in helper.c because they w
In preparation for adding conversions between float16 and float64,
factor out code currently done inline in the float16<=>float32
conversion functions into functions RoundAndPackFloat16 and
NormalizeFloat16Subnormal along the lines of the existing versions
for the other float types.
Note that we c
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> +int64_t v;
> +int_fast16_t res;
> +int old_exc_flags = get_float_exception_flags(status);
> +
> +v = float32_to_int64(a STATUS_VAR);
Any good reason not to use int32 as the intermediate, for the benefit of 32-bit
hosts?
Otherwise,
R
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> +/* We provide the int16 versions for symmetry of API with float-to-int */
> +INLINE float32 int16_to_float32(int_fast16_t v STATUS_PARAM)
> +{
> +return int32_to_float32(v STATUS_VAR);
> +}
If you're going to have int16 versions, I don't think yo
On 31 December 2013 14:18, Richard Henderson wrote:
> On 12/31/2013 05:35 AM, Peter Maydell wrote:
>> +int64_t v;
>> +int_fast16_t res;
>> +int old_exc_flags = get_float_exception_flags(status);
>> +
>> +v = float32_to_int64(a STATUS_VAR);
>
> Any good reason not to use int32 as th
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Tom Musta
>
> The float64_to_uint64_round_to_zero routine is incorrect.
>
> For example, the following test pattern:
>
> 46697351FF4AEC29 / 0x1.97351ff4aec29p+103
>
> currently produces 8000 instead of .
>
>
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Tom Musta
>
> The float64_to_uint32 has several flaws:
>
> - for numbers between 2**32 and 2**64, the inexact exception flag
>may get incorrectly set. In this case, only the invalid flag
>should be set.
>
>test pattern: 425F
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Tom Musta
>
> The float64_to_uint32_round_to_zero routine is incorrect.
>
> For example, the following test pattern:
>
> 425F81378DC0CD1F / 0x1.f81378dc0cd1fp+38
>
> will erroneously set the inexact flag.
>
> This patch re-implements th
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> Tidy up the get/set accessors for the fp state to add missing ones
> and make them all inline in softfloat.h rather than some inline and
> some not.
>
> Signed-off-by: Peter Maydell
> ---
> The specific one we want for A64 is to get the rounding mode
On 31 December 2013 14:21, Richard Henderson wrote:
> On 12/31/2013 05:35 AM, Peter Maydell wrote:
>> +/* We provide the int16 versions for symmetry of API with float-to-int */
>> +INLINE float32 int16_to_float32(int_fast16_t v STATUS_PARAM)
>> +{
>> +return int32_to_float32(v STATUS_VAR);
>>
On 12/31/2013 06:22 AM, Peter Maydell wrote:
> Or do you mean we should call float32_to_int32() instead?
> I think that ought to work...
Yes, that's what I meant.
r~
On 12/31/2013 06:27 AM, Peter Maydell wrote:
> I was going for consistency with the convert-to-int16, which return
> int_fast16_t.
Perhaps, but in that case we've properly bounded the result; it's guaranteed to
be in range of int16_t.
> The existing int32_to_float* functions take int32, not int32
On 31 December 2013 14:35, Richard Henderson wrote:
> On 12/31/2013 06:27 AM, Peter Maydell wrote:
>> The existing int32_to_float* functions take int32, not int32_t,
>> so this is the same semantics. You could argue that it would
>> be better for all of them to take the exact type rather than
>> t
[Tom, this is exactly what you need to fix FRIN rounding.]
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> -float_round_to_zero = 3
> +float_round_to_zero = 3,
> +float_round_ties_away= 4,
I'm not keen on the name. Does anyone else think float_round_nearest_inf is a
bett
On 31 December 2013 14:51, Richard Henderson wrote:
> [Tom, this is exactly what you need to fix FRIN rounding.]
>
> On 12/31/2013 05:35 AM, Peter Maydell wrote:
>> -float_round_to_zero = 3
>> +float_round_to_zero = 3,
>> +float_round_ties_away= 4,
>
> I'm not keen on the
Hello,
I have a setup on CentOS 6.5
Host configuration:
macvlan0-> 10.0.0.2/24
ppp0 -> connected to the internet
Guest configuration
macvtap0-> 10.0.0.4/24
gateway -> 10.0.0.2
Other host on same network
eth0 -> 10.0.0.3/24
gateway -> 10.0.0.2
Ping results
from 10.0.0.2 to 10.0.0.4 and vice ve
On 12/31/2013 06:56 AM, Peter Maydell wrote:
> The IEEE spec specifically calls this roundTiesToAway. I'd rather
> not deviate from the official name unless there's a good reason.
Fair enough.
r~
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Will Newton
>
> Make the VFP_CONV_FIX helpers a little more flexible in
> preparation for the A64 uses. This requires two changes:
> * use the correct softfloat conversion function based on itype
>rather than always the int32 one; this is
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Will Newton
>
> The VFP conversion helpers for A32 round to zero as this is the only
> rounding mode supported. Rename these helpers to make it clear that
> they round to zero and are not suitable for use in the AArch64 code.
>
> Signed-off-by
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> The VFP fixed point conversion helpers first call float_scalbn and
> then convert the result to an integer. This scalbn operation may
> set floating point exception flags for:
> * overflow & inexact (if it overflows to infinity)
> * input denormal sq
On 12/31/2013 05:35 AM, Peter Maydell wrote:
> From: Will Newton
>
> Define the full set of floating point to fixed point conversion
> helpers required to support AArch64.
>
> Signed-off-by: Will Newton
> Signed-off-by: Peter Maydell
> ---
> target-arm/helper.c | 11 ++-
> target-arm/
Il 31/12/2013 09:06, Amos Kong ha scritto:
> When it fails to set properties, qdev's parent is already set
Do not confuse the QOM parent (which is /machine/peripheral, of which
the new device is a child) with the qdev parent bus (which has a link to
the new device)!
In general, you should add the
On Tue, Dec 31, 2013 at 2:43 AM, Peter Bartoli wrote:
>
> On Dec 28, 2013, at 2:00 AM, Artyom Tarasenko wrote:
>
> Actually QEMU does set variables in NVRAM (hw/sparc/sun4m.c:151), and
> afaik uses the layout of open-sourced OBP. The problem is that earlier
> versions of OBP seemed to have a diff
Thanks, Artyom.
Heads up: Solaris 2.5.1 doesn't boot with OpenBIOS. I'll be happy to
help with some regression testing, if you like.
-peter
On Dec 31, 2013, at 8:02 AM, Artyom Tarasenko wrote:
> On Tue, Dec 31, 2013 at 2:43 AM, Peter Bartoli wrote:
>>
>> On Dec 28, 2013, at 2:00 AM, Artyom T
Hello,
I have a setup on CentOS 6.5
Host configuration:
macvlan0-> 10.0.0.2/24
ppp0 -> connected to the internet
Guest configuration
macvtap0-> 10.0.0.4/24
gateway -> 10.0.0.2
Other host on same network
eth0 -> 10.0.0.3/24
gateway -> 10.0.0.2
Ping results
from 10.0.0.2 to 10.0.0.4 and vice ve
Peter:
Happy new year, Today is new year's day, so I will present the v3
patch according to your suggestions tomorrow , thanks for your review.
Faithfully yours
Kewei Yu
2013/12/31 Kewei Yu
> 2013/12/31 Peter Crosthwaite
>
>> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
>> > Whe
On 31 December 2013 13:29, Kewei Yu wrote:
> 2013/12/31 Peter Crosthwaite
>>
>> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
>> >"%s", qemu_binary, s->socket_path,
>> >s->qmp_socket_path, pid_file,
>> > +
2014/1/1 Peter Maydell
> On 31 December 2013 13:29, Kewei Yu wrote:
> > 2013/12/31 Peter Crosthwaite
> >>
> >> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
> >> >"%s", qemu_binary, s->socket_path,
> >> >s->qmp_socket_p
On Wed, Jan 1, 2014 at 12:29 PM, Kewei Yu wrote:
>
> 2014/1/1 Peter Maydell
>>
>> On 31 December 2013 13:29, Kewei Yu wrote:
>> > 2013/12/31 Peter Crosthwaite
>> >>
>> >> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
>> >> >"%s", qemu_binary, s->socket_pa
On Tue, Dec 31, 2013 at 11:29 PM, Kewei Yu wrote:
> 2013/12/31 Peter Crosthwaite
>>
>> On Tue, Dec 31, 2013 at 2:42 PM, Kewei Yu wrote:
>> > When we disabling vnc from "./configure", the qemu can't use the vnc
>> > option.
>>
>> "disable", -"the", "QEMU",
>
> Do you mean "s/disabling/disable; s/
I am trying to debug bootloader with gdb in QEMU. I run QEMU command like
this
./qemu-system-mips64 -s -S -m 1024 -M octeon -bios
u-boot-octeon_ebh5610.bin -kernel vmlinux.64 -append 'coremask=001 mem=0
root=/dev/sda2'
and then connect gdb using
mips64-octeon-linux-gnu-gdb u-boot-octeon_ebh56
58 matches
Mail list logo
