"We think"? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
W
On Wed, Feb 17, 2010 at 8:55 PM, Rob Landley wrote:
> On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
>> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
>> >> I've also got a bunch of "sort of working, but not well enough
>> >> to run builds natively under" targets on top of that (arm
On Mon, 15 Feb 2010 19:42:29 +0100
Markus Armbruster wrote:
> Anthony Liguori writes:
> > Thanks for the write-up. Here's my view of how error reporting ought
> > to work:
> >
> > 0) A user tries to do something via some piece of code that serves as
> > the UI. This may be the -device option
On 02/17/2010 10:34 AM, Blue Swirl wrote:
> On Wed, Feb 17, 2010 at 12:10 AM, Richard Henderson wrote:
>> Previously ANDC was always implemented by tcg-op.h with
>> an explicit NOT opcode. Allow a target implementation.
>
> I think the convention is to add commented out #defines or #undefs for
>
On Wednesday 17 February 2010 09:45:48 Paolo Bonzini wrote:
> On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
> >> I've also got a bunch of "sort of working, but not well enough
> >> to run builds natively under" targets on top of that (arm big
> >> endian, sh4, sparc...)
> >
> > What's not well en
On Wed, Feb 17, 2010 at 12:10 AM, Richard Henderson wrote:
> Previously ANDC was always implemented by tcg-op.h with
> an explicit NOT opcode. Allow a target implementation.
I think the convention is to add commented out #defines or #undefs for
all targets, like sparc in bswap case:
//#define TC
On Wed, Feb 17, 2010 at 1:15 AM, Richard Henderson wrote:
> All of these patches are toward reducing the number of TCG opcodes
> generated. Three of the patches reduce the number of real insns
> generated as well. The ANDC and ORC opcodes are already generated
> by the ARM, PPC, and Alpha transl
Thanks, applied. Please remember the Signed-off-by: line.
On Mon, Feb 15, 2010 at 11:22 PM, Richard Henderson wrote:
> On 02/13/2010 02:01 PM, Blue Swirl wrote:
>> On Tue, Feb 9, 2010 at 11:37 PM, Richard Henderson wrote:
>>> ---
>>> tcg/sparc/tcg-target.c | 126
>>> +
On Wednesday 17 February 2010 03:24:58 Artyom Tarasenko wrote:
> > I've also got a bunch of "sort of working, but not well enough to run
> > builds natively under" targets on top of that (arm big endian, sh4,
> > sparc...)
>
> What's not well enough on sparc?
More than one thing, unfortunately. (
cpu_gdb_read_register(): Fix n={8...15} case.
cpu_gdb_write_register(): Fix n={8...15} case and runaway "case:".
Signed-off-by: Takashi YOSHII
---
gdbstub.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 80477be..3
As "todo" comment in source code.
And modify restore_sigcontext() to have three args as kernel's does.
Signed-off-by: Takashi YOSHII
---
linux-user/signal.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal
On 02/17/2010 10:24 AM, Artyom Tarasenko wrote:
I've also got a bunch of "sort of working, but not well enough
to run builds natively under" targets on top of that (arm big
endian, sh4, sparc...)
What's not well enough on sparc?
From http://permalink.gmane.org/gmane.comp.emulators.qemu/63610:
On linux/sh4
pipe() return values by r0:r1 as SH C calling convention.
pipe2() return values on memory as traditional unix way.
Signed-off-by: Takashi YOSHII
---
linux-user/syscall.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/linux-user/syscall.c b/linux-u
On Tue, Feb 16, 2010 at 05:31:19AM -0500, Michael Casadevall wrote:
> Signed-off-by: Michael Casadevall
Looks correct and passes ltp tests, thanks. Will include these patches
in the next linux-user pull request.
Next time you might want to separate the commit title and message instead
of having
On 02/11/2010 01:23 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
Applied, thanks.
--
error compiling committee.c: too many arguments to function
On 02/11/2010 01:09 AM, Paolo Bonzini wrote:
This patch series morphs the code in qemu-kvm's eventfd so that it looks
like the code in upstream qemu. Patch 4 is not yet in upstream QEMU,
I'm submitting it first to qemu-kvm to avoid conflicts.
Applied, thanks.
--
error compiling committee.
When qemu-img can't open the new backing file for a rebase, it prints an error
message which contains the file name of the old backing file. This is wrong,
obviously.
Signed-off-by: Kevin Wolf
---
qemu-img.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img.c b/q
This fixes a possible read beyond the end of the temporary buffers used for
comparing data in the old and the new backing file.
Signed-off-by: Kevin Wolf
---
qemu-img.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 250d892..258dc62 100644
On 17.02.2010, at 10:47, Avi Kivity wrote:
> On 02/17/2010 11:42 AM, OHMURA Kei wrote:
> "We think"? I mean - yes, I think so too. But have you actually measured
> it?
> How much improvement are we talking here?
> Is it still faster when a bswap is involved?
Thanks for point
On 02/17/2010 11:42 AM, OHMURA Kei wrote:
"We think"? I mean - yes, I think so too. But have you actually
measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test
On 17.02.2010, at 10:42, OHMURA Kei wrote:
"We think"? I mean - yes, I think so too. But have you actually measured
it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
>>> Thanks for pointing out.
>>> I will post the data for x86 later.
"We think"? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we talking here?
Is it still faster when a bswap is involved?
Thanks for pointing out.
I will post the data for x86 later.
However, I don't have a test environment to check the impact of bswap.
W
2010/2/16 Rob Landley :
> On Tuesday 16 February 2010 03:31:16 Alexander Graf wrote:
>> On 16.02.2010, at 01:52, Rob Landley wrote:
>> If swapping the parameter was the right solution I would've submitted a
>> patch long ago :-). Unfortunately it's not as easy.
>
> I agree that making a single cont
23 matches
Mail list logo
