linux specific boot sequence is skipped
because earlier it is asserted that the linux protocol magic field could not be
found.
Signed-off-by: Nathan Kolpa
---
hw/i386/x86.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 2b6291ad8d..b59f11
Public bug reported:
Using QEMU 2.7.0 with KVM enabled, when I launch the guest without
options (using the default of gtk), the mouse wheel events are not
propagated to the guest.
When I start qemu using -display sdk, mouse wheel events are properly
forwarded.
I can determine that the guest is n
at I was getting at: at least just to get things working
>> for testing, just avoid the PRESENT bits in your hot_add_cpu hook rather
>> than patching the guest. Unfortunately the documentation isn't particularly
>> clear about which of these approaches is more correct as far
> + uint32_t token, uint32_t nargs,
>> + target_ulong args, uint32_t nret,
>> + target_ulong rets)
>> +{
>> +uint32_t indicator = rtas_ld(args, 0);
>> +uint32_t dr
cpu and memory).
This happens after the check exception interrupt. In the guest we determine the
drc index for the pci device being added, then makes this rtas call to get the
device tree updates.
-Nathan
>
>
>> ---
>> hw/ppc/spapr_pci.c | 111
>> ++
On Mar 17, 2012, at 11:20 AM, Blue Swirl wrote:
On Sat, Mar 3, 2012 at 16:34, Nathan Whitehorn
wrote:
Fix a missing header required to build on recent FreeBSD.
Signed-off-by: Nathan Whitehorn
---
os-posix.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/os
bout integer "mul" or "div". My question is what did QEMU do when
> they need to emulate a floating point calculation? where are these codes?
All the code for manipulating floating-point numbers is in the fpu directory.
The target-i386 code that calls into those functions is in op_helper.c.
HTH,
-Nathan
realize that without information from the kernel about the instruction
ranges for each application I will be unable to tie this information
back to which applications were running.
Any tips / help anyone can provide would be very useful.
Tha
** Patch added: "mtmstr.diff"
https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/788697
Title:
[PowerPC] [patch] mtmsr do
Public bug reported:
The mtmsr instruction on 64-bit PPC does not preserve the high-order
32-bits of the MSR the way it is supposed to, instead setting them to 0,
which takes 64-bit code out of 64-bit mode. There is some code that does
the right thing, but it brokenly only preserves these bits whe
On 05/26/11 11:45, agraf wrote:
> On 26.05.2011, at 18:09, Nathan Whitehorn wrote:
>
>> ** Patch added: "mtmstr.diff"
>>
>> https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff
>>
>> --
>> You received this bug notifi
On 05/26/11 18:47, agraf wrote:
> On 27.05.2011, at 01:33, Nathan Whitehorn wrote:
>
>> On 05/26/11 11:45, agraf wrote:
>>> On 26.05.2011, at 18:09, Nathan Whitehorn wrote:
>>>
>>>> ** Patch added: "mtmstr.diff"
>>>>
>&g
The PIR register is architecturally specified on all PowerPC
non-embedded CPUs, but currently is only available on the 604, 620, and
G4. Add it to all 601-derived CPUs.
target-ppc/translate_init.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/targ
The mtmsr instruction is required not to modify the upper 32-bits of the
machine state register, but checks the current value of MSR[SF] to
decide whether to do this. This has the effect of zeroing the upper 32
bits of the MSR whenever mtmsr is executed in 64-bit mode.
Unconditionally preserve
Add some includes required to build qemu on FreeBSD.
---
bsd-user/syscall.c |2 ++
iohandler.c|1 +
os-posix.c |4
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index eb1cdf2..7b49f54 100644
--- a/bsd-user/
On 05/31/11 12:40, Richard Henderson wrote:
On 05/31/2011 07:56 AM, Nathan Whitehorn wrote:
#if defined(TARGET_PPC64)
-if (!ctx->sf_mode) {
TCGv t0 = tcg_temp_new();
TCGv t1 = tcg_temp_new();
You're removing a scope in which these variables were
On 06/05/11 04:00, Alexander Graf wrote:
On 04.06.2011, at 21:28, Nathan Whitehorn wrote:
On 05/31/11 12:40, Richard Henderson wrote:
On 05/31/2011 07:56 AM, Nathan Whitehorn wrote:
#if defined(TARGET_PPC64)
-if (!ctx->sf_mode) {
TCGv t0 = tcg_temp_
On 06/05/11 08:33, Nathan Whitehorn wrote:
On 06/05/11 04:00, Alexander Graf wrote:
On 04.06.2011, at 21:28, Nathan Whitehorn wrote:
On 05/31/11 12:40, Richard Henderson wrote:
On 05/31/2011 07:56 AM, Nathan Whitehorn wrote:
#if defined(TARGET_PPC64)
-if (!ctx->sf_m
On 06/02/11 10:01, Andreas Färber wrote:
Am 31.05.2011 um 16:57 schrieb Nathan Whitehorn:
Add some includes required to build qemu on FreeBSD.
Missing Sob.
Oops, I'll resubmit.
---
bsd-user/syscall.c |2 ++
iohandler.c|1 +
os-posix.c |4
3 files chang
the upper 32-bits in mtmsr for TARGET_PPC64.
Signed-off-by: Nathan Whitehorn
---
target-ppc/translate.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 59aef85..38d2e2e 100644
--- a/target-ppc/translate.c
+++ b
The PIR register is architecturally specified on all PowerPC
non-embedded CPUs, but currently is only available on the 604, 620, and
G4. Add it to all 601-derived CPUs.
Signed-off-by: Nathan Whitehorn
---
target-ppc/translate_init.c | 20 +---
1 files changed, 5 insertions
On 06/13/11 05:20, Alexander Graf wrote:
Am 12.06.2011 um 17:49 schrieb Nathan Whitehorn:
The mtmsr instruction is required not to modify the upper 32-bits of the
machine state register, but checks the current value of MSR[SF] to decide
whether to do this. This has the effect of zeroing
Fix a missing header required to build on recent FreeBSD.
Signed-off-by: Nathan Whitehorn
---
os-posix.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/os-posix.c b/os-posix.c
index dbf3b24..83b14a0 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -45,6 +45,10
: Nathan Whitehorn
---
target-ppc/translate_init.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 8a7233f..01f4030 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6537,6
Recent changes to the signature of usb_host_device_open() have broken
the stub USB backend. This updates the stub version of
usb_host_device_open() to correspond to the new API.
Signed-off-by: Nathan Whitehorn
---
usb-stub.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
.
Signed-off-by: Nathan Whitehorn
---
target-ppc/helper.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 928fbcf..0f5ad2e 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -597,12 +597,6 @@ static inline int
On Mar 7, 2012, at 7:25 PM, David Gibson wrote:
On Sat, Mar 03, 2012 at 10:39:34AM -0600, Nathan Whitehorn wrote:
Fix large page support in TCG. The old code would overwrite the
large page table entry with the fake 4 KB
one generated here whenever the ref/change bits were updated,
causing it
On 03/09/12 07:13, Alexander Graf wrote:
On 09.03.2012, at 04:42, David Gibson wrote:
On Thu, Mar 08, 2012 at 09:24:53AM -0600, Nathan Whitehorn wrote:
On Mar 7, 2012, at 7:25 PM, David Gibson wrote:
On Sat, Mar 03, 2012 at 10:39:34AM -0600, Nathan Whitehorn wrote:
Fix large page support
like the device
does not exist), although it was in the qemu console.
- iBoot is the only solution I found so far capable of actually
starting the boot process (at least the first 0.1 seconds of it...)
Thank you
--
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PS
This patch fixes the spacing of the PC and NPC output from 'info cpus'
for SPARC.
Signed-off-by: Nathan Kunkee
diff --git a/monitor.c b/monitor.c
index 1b8ba2c..16cd4c5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -884,9 +884,9 @@ static void print_cpu_iter(QObject *obj, vo
On 12/02/13 12:58, Paolo Bonzini wrote:
> Il 02/12/2013 18:51, Nathan Whitehorn ha scritto:
>> Any news on this? FreeBSD is unbootable from CDROM devices in
>> QEMU/pseries without this patch.
>> -Nathan
> Acked-by: Paolo Bonzini
>
> Alex, can you pick it up?
Any updates?
-Nathan
On 01/02/14 10:41, Alexander Graf wrote:
> On 02.01.2014, at 16:31, Alexander Graf wrote:
>
>> On 18.10.2013, at 14:33, Nathan Whitehorn wrote:
>>
>>> Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the
>>> well-known
>>> LUN
On 01/02/14 10:31, Alexander Graf wrote:
> On 18.10.2013, at 14:33, Nathan Whitehorn wrote:
>
>> Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the
>> well-known
>> LUN for REPORT_LUNS commands. This is required to implement the SAM and SPC
>> s
On 01/02/14 10:56, ronnie sahlberg wrote:
> On Thu, Jan 2, 2014 at 7:41 AM, Alexander Graf wrote:
>> On 02.01.2014, at 16:31, Alexander Graf wrote:
>>
>>> On 18.10.2013, at 14:33, Nathan Whitehorn wrote:
>>>
>>>> Intercept REPORT_LUNS commands ad
commands addressed to any other LUN is not specified
by the standard and so is left unchanged. This preserves behavior under Linux
and SLOF, which enumerate possible LUNs by hand and so address no commands
either to LUN 0 or the well-known REPORT_LUNS LUN.
Signed-off-by: Nathan Whitehorn
--
hw/scsi
On 01/03/14 08:27, Paolo Bonzini wrote:
> Il 02/01/2014 19:23, Nathan Whitehorn ha scritto:
>>>> Let me try to grasp what you're doing here. You're trying to
>>>> figure out how many devices there are attached to the bus. For
>>>> every device y
Any news on this? FreeBSD is unbootable from CDROM devices in
QEMU/pseries without this patch.
-Nathan
On 10/18/13 07:33, Nathan Whitehorn wrote:
Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the well-known
LUN for REPORT_LUNS commands. This is required to implement the SAM
; Developers; Andreas Färber; Nathan Rossi
> Subject: Re: [Qemu-devel] [PATCH qom v1 1/1] qom/object.c: Split out
> object and class caches.
>
> Hi
>
> On Wed, Dec 4, 2013 at 1:40 AM, Paolo Bonzini wrote:
> > Il 28/11/2013 05:27, Peter Crosthwaite ha scritto:
> >>
commands addressed to any other LUN is not specified
by the standard and so is left unchanged. This preserves behavior under Linux
and SLOF, which enumerate possible LUNs by hand and so address no commands
either to LUN 0 or the well-known REPORT_LUNS LUN.
Signed-off-by: Nathan Whitehorn
---
hw/scsi
Public bug reported:
I attempted to install ESXi 5.5 (the free version) into a QEmu 1.6.1 VM.
The guest OS does have the svm capabilities, but it appears VMware is
trying to do some kind of hypercall that crashes the guest.
There is more information here:
https://communities.vmware.com/message/22
oesn't call for it - so I didn't.
Signed-off-by: Nathan Baum
---
ui/vnc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index a742c90..200cdd7 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1893,7 +1893,22 @@ static void do_key_eve
I wasn't sure whether to do this for all the modifiers - my use case
doesn't call for it - so I didn't.
Signed-off-by: Nathan Baum
---
ui/vnc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index a742c90..acfb24e 10064
t;> Quoting David Gibson (2015-01-16 00:21:55)
>>>>>> On Tue, Dec 23, 2014 at 06:30:17AM -0600, Michael Roth wrote:
>>>>>>> From: Nathan Fontenot
>>>>>>>
>>>>>>> Signed-off-by: Nathan Fontenot
>>>>>&
I just tried running x86 windows program, on x86 wine, on qemu-i386, all
on an arm host. I am also experiencing a hung wine and wineserver. Was
this bug ever fixed?
** Also affects: wine (Gentoo Linux)
Importance: Undecided
Status: New
--
You received this bug notification because you
ons where some LMB's are not
removed and some are.
-Nathan
> Signed-off-by: Bharata B Rao
> ---
> Changes in v1:
> - Got rid of the patch that introduced a field in PCDIMMDevice to track
> DIMM marked for removal since we can track that using within DRC
> object.
&
On Thu, Feb 4, 2016 at 10:34 AM, Alistair Francis
wrote:
> Signed-off-by: Alistair Francis
Tested-by: Nathan Rossi
> ---
>
> target-arm/cpu-qom.h | 2 ++
> target-arm/cpu.c | 2 ++
> target-arm/cpu64.c | 2 ++
> target-arm/helper.c | 8
> 4 file
On Thu, Feb 4, 2016 at 10:34 AM, Alistair Francis
wrote:
> This patch adds the following registers including read and write functions:
> PMSELR, PMSELR_EL0, PMXEVCNTR, PMXEVCNTR_EL0, PMXEVTYPER and PMXEVTYPER_EL0.
>
> Signed-off-by: Alistair Francis
Tested-by: Nathan Rossi
>
On Thu, Feb 4, 2016 at 10:34 AM, Alistair Francis
wrote:
> Signed-off-by: Alistair Francis
Tested-by: Nathan Rossi
> ---
>
> target-arm/helper.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/target-arm/helper.c b/target-arm/helper.c
> index
h
can in turn lead to page faults.
The fix is simple: add a special case for these instructions. It did not
fit cleanly into the existing case, so some cut-and-paste was necesary.
Signed-off-by: Nathan Froyd
---
target-i386/translate.c | 10 ++
1 file changed, 10 insertions(+)
diff --
i64/f64 values is not healthy.
But Peter's already said that the floats-as-structs bit of softfloat is
broken, so maybe it's not worth trying to ensure floats-as-structs works
(or even making it the default, to discourage people from bit-twiddling
directly).
-Nathan
op2);
> }
is not correct, as you've just turned this into an infinite (inlined!)
loop. You'd want to change the efststlt call into an efscmplt call.
Similarly for efstst{gt,eq}.
-Nathan
float's domain in some sense.) That would move the 'propagate one
> of 3 NaNs' logic into softfloat.
+1 to implementing fma in softfloat.
-Nathan
mbs in the dynamic-reconfiguration property.
Just wanting to make sure I'm understanding how this is working.
Also, since the memory specified in the memory@XXX nodes is not removable this
should not break any of the userspace tools.
-Nathan
> Signed-off-by: B
memory hotplug
> request can't be fulfilled due to insufficient HTAB size. (Anshuman can
> elaborate on this with the exact description on why it is so hard to
> recover).
>
> Do you think disabling memory hotplug upfront is a reasonable workaround
> for this problem ?
>
&
On 09/04/2015 10:33 AM, Michael Roth wrote:
> Quoting Nathan Fontenot (2015-09-03 13:50:59)
>> On 09/01/2015 10:28 PM, Bharata B Rao wrote:
>>> On Mon, Aug 24, 2015 at 09:01:51AM +0530, Bharata B Rao wrote:
>>>> The hash table size allocated to guest depends on the
The GIC in ZynqMP cover a 64K address space, however the actual
registers are decoded within a 4K address space and mirrored at the 4K
boundaries. This change fixes the defined size for these regions as it
was set to 0x4000/16K incorrectly.
Signed-off-by: Nathan Rossi
---
include/hw/arm/xlnx
t;> There may be more changes worth making on is_linux. I don't have the
>>>> patch with the full list of FSBL-related SLCR changes handy and can't
>>>> seem to find it in any modern Yocto trees. Wondering if Yocto still
>>>> supports booting Zynq without F
onse to those
>> calls. IIUC, you are suggesting that lets remove one LMB by index in
>> response to 1st message and remove (count -1) LMBs from where the last
>> removal was done in the previous message.
>
> Yes, that's the idea.
>
>> Since the same code base
ed by guest.
What does qemu do if a guest tries to add or remove a reserved LMB?
Asking because the current guest code (drmgr and kernel) does not
take the reserved flag into consideration when searching for lmbs to
add/remove. This seems like something I should be fixed on the guest
side.
-Nath
On 06/06/2016 09:47 AM, Bharata B Rao wrote:
> On Mon, Jun 06, 2016 at 09:14:48AM -0500, Nathan Fontenot wrote:
>> On 06/06/2016 06:37 AM, Bharata B Rao wrote:
>>> Memory hotplug can fail for some combinations of RAM and maxmem when
>>> DDW is enabled in the presence o
these LMBs are not considered
> by the guest.
>
> Signed-off-by: Bharata B Rao
Reviewed-by: Nathan Fontenot
> ---
> Changes in v4:
>
> - Included address information for all LMBs in ibm,dynamic-memory.
> - Use both RESERVED and DRC_INVALID flag bits for non-hotpluggab
translation code accordingly.
Signed-off-by: Nathan Froyd
---
target-mips/helper.h|8
target-mips/op_helper.c | 28
target-mips/translate.c |8
3 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/target-mips/helper.h b
major changes, we can comfortably run programs like the
above without exhausting memory. We do need to delete 'stack' from the
TaskState structure.
Signed-off-by: Nathan Froyd
---
linux-user/main.c|4 ++--
linux-user/qemu.h|2 --
linux-user/syscall.c | 11 +++
3
eum is broken, the bug is in
> my code.)
FWIW, the Intel manuals (253666, June 2010) state that the ZF flag is
unaffected, not just undefined.
-Nathan
ect if FP traps are disabled.
(Also, the arm routines returning float* values is just awful. Not your
fault, just a comment.)
-Nathan
p in. Generic
> qemu stuff I can always talk about ;)
I would be happy to come and give an overview talk. I don't know that
our process for getting in patches that are non-x86+virtualization
related are really that good, but perhaps we can have a discussion about
that so that we have a better story to tell by March. :)
-Nathan
dows host support. (We
distribute QEMU with our commerical development products for
ARM/PowerPC/MIPS/SH/ColdFire/x86.) Unfortunately, we've mostly been
backporting patches lately and haven't done a full merge from upstream
in some time, so we haven't noticed any potential breakage. If somebody
wanted to point out to me what the (potential) Windows issues are, we
could take a look.
-Nathan
On Sun, Nov 28, 2010 at 09:20:25AM +0100, Frédéric Pétrot wrote:
>IMHO someone from code sourcery would be great, as they (Paul Brooks in the
>older versions, it seems that Nathan is now taking over) are contributing
>most of the ARM emulation stuff.
Well, Paul still knows
On Mon, Nov 29, 2010 at 08:34:28AM -0600, Anthony Liguori wrote:
> On 11/28/2010 04:56 AM, Alexander Graf wrote:
>> On 28.11.2010, at 01:17, Nathan Froyd wrote:
>>> We (CodeSourcery) are very interested in Windows host support. (We
>>> distribute QEMU with our commeric
On Mon, Nov 29, 2010 at 02:58:57PM +0100, Alexander Graf wrote:
> > Nathan Froyd a écrit :
> >> I'm sorry, what are the "both talks" you refer to above? Are you
> >> proposing an additional talk alongside your (Frédéric's) existing talk?
> >
On Tue, Nov 23, 2010 at 06:53:45PM +, Peter Maydell wrote:
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
float64_val(x) & ~(1ULL << 63)) > 0x7ff0ULL);
> +}
Why not just use:
static int float32_is_any_nan(float32 x)
{
return float32_is_nan(x) || float32_is_signaling_nan(x);
}
and likewise for the 64-bit case?
-Nathan
On Mon, Nov 29, 2010 at 04:49:24PM +, Peter Maydell wrote:
> On 29 November 2010 16:38, Nathan Froyd wrote:
> > Why not just use:
> >
> > static int float32_is_any_nan(float32 x)
> > {
> > return float32_is_nan(x) || float32_is_signaling_nan(x);
> > }
&
off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
at least 16 bits wide (and so is usually 32 bits).
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
(float64_val(r) | (1LL << 51));
> +}
> +return r;
> }
As with other NaN-handling patches, I don't think the bit-twiddling here
is a good idea. Having a float*_maybe_silence_nan function in softfloat
would be a better approach.
-Nathan
was inverted
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
er Maydell
Reviewed-by: Nathan Froyd
-Nathan
ngtsson
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
l
Reviewed-by: Nathan Froyd
-Nathan
rs to userspace signal handlers.)
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
ux-user mode.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
g compatible with the older kernels, which don't save and
> restore VFP registers either.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
m to deliberately modify the state via the ucontext structure.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
m to deliberately modify the state via the ucontext structure.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> On 29 November 2010 17:49, Nathan Froyd wrote:
> > On Tue, Nov 23, 2010 at 06:53:47PM +, Peter Maydell wrote:
> > As with other NaN-handling patches, I don't think the bit-twiddling here
> > is a
On Mon, Nov 29, 2010 at 08:04:42PM +, Peter Maydell wrote:
> On 29 November 2010 19:54, Nathan Froyd wrote:
> > On Mon, Nov 29, 2010 at 07:25:18PM +, Peter Maydell wrote:
> >> (b) add to and extend the softfloat API whenever you have some
> >> floating-poi
On Tue, Nov 30, 2010 at 11:15:56AM +, Peter Maydell wrote:
> On 29 November 2010 19:54, Nathan Froyd wrote:
> > Yes, this is ugly. Are you up for running:
> >
> > perl -p -i -e 's/float(\d+)_is_nan/float\1_is_quiet_nan/g' target-*/*.c
> >
> > (
s_quiet_nan uses with new function
-Nathan
t; This change was produced by:
> perl -p -i -e 's/_is_nan/_is_quiet_nan/g' $(git grep -l is_nan)
> (with the results manually checked.)
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
Thank you for doing this.
-Nathan
On Thu, Nov 11, 2010 at 06:23:55PM +, Peter Maydell wrote:
> Correct the decoding of source and destination registers
> for the VFP forms of the VCVT instructions which convert
> between floating point and integer or fixed-point.
>
> Signed-off-by: Peter Maydell
Reviewed-b
7;m sure clever engineering
could be applied to make them smaller.
Of course, the *real* problems are in undefined-behavior land. :)
-Nathan
On Mon, Dec 06, 2010 at 05:00:05PM +, Peter Maydell wrote:
> Add float*_is_any_nan() functions which return true if the argument
> is a NaN of any kind (quiet or signalling).
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
On Mon, Dec 06, 2010 at 05:00:07PM +, Peter Maydell wrote:
> Add functions float*_maybe_silence_nan() which ensure that a
> value is not a signaling NaN by turning it into a quiet NaN.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
be special-cased.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
of the low word.
>
> This fixes the issues reported in
> https://bugs.launchpad.net/qemu/+bug/670883
>
> Signed-off-by: Peter Maydell
Reviewed-by: Nathan Froyd
-Nathan
d:
typedef uint8_t flag;
typedef uint8_t uint8;
typedef int8_t int8;
typedef int uint16;
typedef int int16;
typedef unsigned int uint32;
typedef signed int int32;
typedef uint64_t uint64;
typedef int64_t int64;
So adding _t suffixes in appropriate places should be a no-op, except
for uint16/int16--and those types are never used.
-Nathan
On Sat, Dec 18, 2010 at 10:39:05AM +, Peter Maydell wrote:
> On 18 December 2010 02:30, Nathan Froyd wrote:
> > So adding _t suffixes in appropriate places should be a no-op, except
> > for uint16/int16--and those types are never used.
>
> Eh? If you comment out the int1
1 - 100 of 317 matches
Mail list logo
