> My use case here is testing and debugging, so I think we could live with
> the blocks being executed in an interleaved fashion until someone has
> the ultimate parallelization solution for upstream.
So you prefer parallelizing QEMU itself in your case?
--
Wei-Ren Chen (陳韋任)
Computer Systems
Am 03.10.2011 12:32, schrieb Andreas Färber:
> -cpu arm1136-r2 is commented to in fact be ARM1136 r0p2, whereas
> -cpu arm1136 seems to be ARM1136 r1p3 according to the MIDR value.
>
> The CPUID values contain major and minor revision numbers (rnpn) and
> are never used with a mask, so are specifi
On 21 October 2011 23:05, Andreas Färber wrote:
> Am 21.10.2011 08:58, schrieb Peter Maydell:
>> (For several
>> of the ARM boards we currently just ignore the fact that the real
>> h/w has a Cortex-M3 doing power management type stuff.)
>
> Mind to share which boards? I'm only aware of the NXP LP
On 3 October 2011 11:32, Andreas Färber wrote:
> -#define ARM_CPUID_ARM1136 0x4117b363
> -#define ARM_CPUID_ARM1136_R2 0x4107b362
> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
I don't think the patchlevels are important enough to
memorialise in the
From: Khansa Butt
Signed-off-by: Khansa Butt
---
target-mips/translate.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index d5b1c76..0550333 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -127
From: Khansa Butt
Signed-off-by: Khansa Butt
---
linux-user/signal.c | 438 +--
1 files changed, 426 insertions(+), 12 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 59c3c88..f5f8bba 100644
--- a/linux-user/signal.c
+
From: Khansa Butt
Signed-off-by: Khansa Butt
---
configure |1 +
default-configs/mips64-linux-user.mak |1 +
linux-user/main.c | 21 +++--
linux-user/mips64/syscall.h |2 ++
linux-user/signal.c
From: Khansa Butt
Signed-off-by: Khansa Butt
---
mips-dis.c | 53 +
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/mips-dis.c b/mips-dis.c
index e3a6e0b..96ab1e8 100644
--- a/mips-dis.c
+++ b/mips-dis.c
@@ -300,6 +300,7 @@
Am 22.10.2011 12:20, schrieb Peter Maydell:
> On 3 October 2011 11:32, Andreas Färber wrote:
>> -#define ARM_CPUID_ARM1136 0x4117b363
>> -#define ARM_CPUID_ARM1136_R2 0x4107b362
>> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
>> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
>
> I don't think the
From: Khansa Butt
Signed-off-by: Khansa Butt
Signed-off-by: Ehsan Ul Haq
Signed-off-by: Abdul Qadeer
Signed-off-by: Abdul Waheed
---
target-mips/cpu.h |7 +
target-mips/helper.h|5 +
target-mips/machine.c | 12 ++
target-mips/op_helper.c | 73
target-mips/tr
From: Khansa Butt
This is the team work of Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt
from HPCN Lab KICS UET Lahore.
Sorry Richard! gen_set was missed.
v1 contains:
* SEQI and SEQ related changes specified by Richard Henderson
* Fix issues related to coding style, typos and misleading
From: Khansa Butt
Signed-off-by: Khansa Butt
---
target-mips/mips-defs.h |2 ++
target-mips/translate_init.c | 24
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index bf094a3..e1ec2b2 100644
Previously the CPUID register was set in cpu_arm_init() based on -cpu
model. The CPU was then reset, requiring to save the CPUID and restore
it afterwards.
Change the storage location of c0_cpuid so that it does not get cleared.
OMAP appears to be special in that the CPUID can be switched between
2011/10/22 xunxun :
> 于 2011/10/22 13:13, xunxun 写道:
>>
>> Hi, all
>>
>> It seems that gcc's auto-omit-frame-pointer has other problems.
>>
>> The example is from mingw bug tracker:
>> http://sourceforge.net/tracker/?func=detail&aid=3426555&group_id=2435&atid=102435
>>
>> g++ -O3 main.cpp
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk:
> From: Khansa Butt
>
> This is the team work of Ehsan-ul-Haq, Abdul Qadeer, Abdul Waheed, Khansa Butt
> from HPCN Lab KICS UET Lahore.
>
> Sorry Richard! gen_set was missed.
When I say further description is missing, I mean: Please add at least
Am 22.10.2011 12:11, schrieb kha...@kics.edu.pk:
> From: Khansa Butt
Commit message should mention here at least that new registers are
introduced and that load/save format is being changed.
> Signed-off-by: Khansa Butt
> Signed-off-by: Ehsan Ul Haq
> Signed-off-by: Abdul Qadeer
> Signed-off-
On 2011-10-20 23:34, Kai Tietz wrote:
> Hi,
>
> For trunk-version I have a tentative patch for this issue. On 4.6.x
> and older branches this doesn't work, as here we can't differenciate
> that easy between ms- and sysv-abi.
>
> But could somebody give this patch a try?
>
> Regards,
> Kai
>
>
On 21.10.2011, at 11:44, Paolo Bonzini wrote:
> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>> Avi complained that not even writing out qcow2's cache on bdrv_flush() made
>> cache=unsafe too unsafe to be useful. He's got a point.
>
> Why? cache=unsafe is explicitly allowing to s/data/manure/ on cr
Hello Mr. Johannes, Kevin
I already did some work for scanning only top level directory in vvfat.
Using the following logic in read_directory()
if(parent_index >= 0 & (!dot & !dotdot))
{
free(buffer);
break;
}
Hope this is correct logic for skipping sub-directories content by
just
Hi Pintu,
On Sat, 22 Oct 2011, Pintu Kumar wrote:
> I already did some work for scanning only top level directory in vvfat.
> Using the following logic in read_directory()
>
> if(parent_index >= 0 & (!dot & !dotdot))
> {
>free(buffer);
>break;
> }
Sorry, this is way too deep in
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Rename the ARM_FEATURE_DIV feature bit to _THUMB_DIV, to
> make room for a new feature switch enabling DIV in the ARM
> encoding. (Cores may implement either (a) no divide insns
> (b) divide insns in Thumb encodings only (c) divide insns
> in both ARM a
Am 20.10.2011 15:16, schrieb Peter Maydell:
> Add support for UDIV and SDIV in ARM mode. This is a new optional
> feature for A profile cores (Thumb mode has had UDIV and SDIV for
> M profile cores for some time).
>
> Signed-off-by: Peter Maydell
Lightly ...
Tested-by: Andreas Färber
Andreas
The Buildbot has detected a new failure on builder xen_i386_debian_6_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_6_0/builds/69
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Reason:
Adding an offset to a void pointer works with gcc but is not allowed
by the current C standards. With -pedantic, gcc complains:
exec-all.h:344: error: pointer of type ‘void *’ used in arithmetic
Fix this, and also replace (unsigned int) by (uintptr_t) in the same
statement.
Signed-off-by: Stefan
24 matches
Mail list logo
