On Fri, Apr 20, 2012 at 04:25, Xin Tong wrote:
> On Thu, Apr 19, 2012 at 6:56 PM, Xin Tong wrote:
>> On Thu, Apr 19, 2012 at 1:03 PM, Blue Swirl wrote:
>>> On Thu, Apr 19, 2012 at 01:55, Xin Tong wrote:
but should not the address be within 1 - 4G-1 even with PAE. is not
the PAE just u
On Fri, Apr 20, 2012 at 12:45, Alexander Graf wrote:
>
> On 16.04.2012, at 21:46, Blue Swirl wrote:
>
>> On Mon, Apr 16, 2012 at 19:28, Peter Maydell
>> wrote:
>>> On 16 April 2012 20:12, Blue Swirl wrote:
On Mon, Apr 16, 2012 at 16:53, Alexander Graf wrote:
> If you can update it on
On Thu, Apr 19, 2012 at 20:26, Blue Swirl wrote:
> In this version, I only fix Sparc.
>
> When switching to qtest_enabled(), I noticed that qtest.o is not
> linked to user emulators (doesn't make sense there). To avoid a build
> breakage, I added dummy stubs in 2/4.
Pushed with 3/4 changed like P
On 2012-04-20 17:36, Eduardo Habkost wrote:
> On Fri, Apr 20, 2012 at 05:19:17PM +0200, Jan Kiszka wrote:
>> On 2012-04-20 17:00, Eduardo Habkost wrote:
>>> On Fri, Apr 20, 2012 at 12:12:38PM +0200, Jan Kiszka wrote:
On 2012-04-19 22:03, Eduardo Habkost wrote:
> Jan/Avi: ping?
>
>
On 21 April 2012 06:44, Andreas Färber wrote:
> MAINTAINERS file is newer than most devices, so many are still missing.
>
> I don't think that grouping devices with the TCG target is a good idea.
>
> My reasoning for adding the Zynq devices to the machine was that it
> seemed a natural fit - both
On Fri, 2012-04-20 at 12:09 +0100, Stefan Hajnoczi wrote:
> On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini wrote:
> > Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
> > - no support for migration (there can be pending SCSI requests at
> > migration time, that need to be restarted on the
On Sat, Apr 21, 2012 at 08:01:18AM +0200, Andreas Färber wrote:
> Am 12.04.2012 01:00, schrieb Andreas Färber:
> > Hello Edgar,
> >
> > This series strips down my CRIS QOM'ification patch from the
> > qom-cpu-others.v1
> > RFC series and splits it into multiple steps. I still think the code is
>
From: "NODA, Kai"
GHashTableIter was first introduced in glib 2.16.
This patch removes it in favor of older g_hash_table_find()
for better compatibility with RHEL5.
Signed-off-by: NODA, Kai
---
Added sign-off. Sorry for inconvenience!
qapi/qmp-input-visitor.c | 25 +---
On Mon, Apr 16, 2012 at 16:25, Peter Maydell wrote:
> On 20 March 2012 15:36, Peter Maydell wrote:
>> On 20 March 2012 15:24, Juan Quintela wrote:
>>> This change makes it compile and return the same value than the #undef one.
>>>
>>> Signed-off-by: Juan Quintela
>>
>> Oops, that would have bee
On Sun, Apr 15, 2012 at 21:47, Max Filippov wrote:
> Fix accidently broken translation of two looping instructions
> by decoupling it from SR write handler. Add unit tests.
Thanks, applied all.
>
> Max Filippov (2):
> target-xtensa: fix LOOPNEZ/LOOPGTZ translation
> target-xtensa: add tests fo
On Mon, Apr 16, 2012 at 17:54, Peter Maydell wrote:
> gdbstub isn't my domain, patches should go via Anthony or Blue
> I guess. Patchwork url:
> http://patchwork.ozlabs.org/patch/146153/
Thanks, applied.
>
> thanks
> -- PMM
>
> On 16 April 2012 18:49, Alexander Graf wrote:
>> Looks great to me
On Tue, Apr 17, 2012 at 17:22, Stefan Weil wrote:
> Change the data type of tci_tb_ptr, so GETPC() returns an
> uintptr_t now (like for all other TCG targets).
>
> This completes commit 2050396801ca0c8359364d61eaadece951006057
> and fixes builds with TCI.
>
> Signed-off-by: Stefan Weil
Thanks, a
On Fri, Apr 20, 2012 at 17:44, Peter Maydell wrote:
> Hi; this is a pullreq for the arm-devs queue, fairly minor stuff.
> Please pull.
Thanks, pulled.
>
> thanks
> -- PMM
>
> The following changes since commit 51006bbc45bc74977ae538190a53df2af534acb9:
>
> Merge remote-tracking branch 'origin/ma
On 04/19/2012 02:55 PM, Max Filippov wrote:
> On Thu, Apr 19, 2012 at 5:33 PM, Richard Henderson wrote:
>> The xtensa-test image generates a sra_i32 with count 0x40.
>
> Richard, what is that xtensa-test image that you refer?
http://wiki.qemu.org/Testing
near the bottom.
r~
Move CTR (cache type register) value to an ARMCPU field
set up by per-cpu init fns.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |1 +
target-arm/cpu.c | 22 ++
target-arm/helper.c | 13 +
3 files changed, 24 inserti
Move the reset FPSID to the ARMCPU struct, and set it in the
per-implementation instance init function. At reset we then
just copy the reset value into the CPUARMState field.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |1 +
target-arm/cpu.c |9 +++
Move the reset value of SCTLR to ARMCPU, initialised in
the per-cpu init functions. It can then be reset by a
simple copy, and we can drop the code from cpu_reset_model_id().
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |1 +
target-arm/cpu.c | 23 +++
None of the machines in QEMU offer a JTAG debug interface, so this info
was unused. Further, the PXA250 ID contradicts the February 2002
Developer's Manual, which has it as 0xn9264013 with n the MIDR Revision.
Signed-off-by: Andreas Färber
Signed-off-by: Peter Maydell
---
target-arm/helper.c |
cpu_reset_model_id() is now empty and we can remove it.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/helper.c | 59 +--
1 files changed, 1 insertions(+), 58 deletions(-)
diff --git a/target-arm/helper.c b/target-arm/help
Now that cpu_reset_model_id() has gone we can move the
reset code over to the class reset function and have cpu_state_reset
simply do a reset on the CPU QOM object.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu.c| 94 +
Hi; this is a pullreq for target-arm. It's got a trivial patch from Benoit
that I've been holding onto for ages, plus the first 13 of the QOM
subclass/reset patches [with the trivial fixes to the bits pointed out
by Andreas]. (Patch 14 I've left out to give Andreas' patch adjusting it
some review t
From: Benoit Canet
Signed-off-by: Benoit Canet
Signed-off-by: Peter Maydell
---
target-arm/cpu.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c208c80..d2f5c76 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -360,6
Move the OMAP-specific cp15_i_{max,min} reset to cpu_state_reset;
since these registers are only accessible on CPUs with the
OMAPCP feature set there's no need to guard this reset with
either a CPUID or feature bit check.
Signed-off-by: Peter Maydell
Reviewed-by: Andreas Färber
---
target-arm/h
Move the MVFR* VFP feature register values to ARMCPU,
so they are set up by the implementation-specific instance
init functions rather than in cpu_reset_model_id().
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |2 ++
target-arm/cpu.c | 14
Move feature register value setup to per-CPU init functions.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h | 14 +++
target-arm/cpu.c | 94 ++
target-arm/helper.c | 73 +++
Move cache ID register reset out of cpu_reset_model_id() by
creating a field for the reset value in ARMCPU and setting it
up in the cpu specific init functions.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |5 +
target-arm/cpu.c | 11 +++
Move the iWMMXT wCID reset to cpu_state_reset(). Since
we use the same value for all CPUs with this feature
(with the major/minor revision fields set to the QEMU
specific 'Q' value) there's no need to create an ARMCPU
field just for this.
Signed-off-by: Peter Maydell
Reviewed-by: Andreas Färber
Register subclasses for each ARM CPU implementation.
Let arm_cpu_list() enumerate CPU subclasses in alphabetical order,
except for special value "any".
Replace cpu_arm_find_by_name()'s string -> CPUID lookup by storing the
CPUID (aka MIDR, Main ID Register) value in the class.
Signed-off-by: And
Move the setting of the feature bits from cpu_reset_model_id()
to each CPU's instance init function. This requires us to move
the features field in CPUARMState so that it is not cleared
on reset.
Signed-off-by: Peter Maydell
Acked-by: Andreas Färber
---
target-arm/cpu-qom.h |1 +
target-arm
On Sat, Apr 21, 2012 at 3:06 AM, Blue Swirl wrote:
> On Fri, Apr 20, 2012 at 04:25, Xin Tong wrote:
>> On Thu, Apr 19, 2012 at 6:56 PM, Xin Tong wrote:
>>> On Thu, Apr 19, 2012 at 1:03 PM, Blue Swirl wrote:
On Thu, Apr 19, 2012 at 01:55, Xin Tong wrote:
> but should not the address be
On Mon, Apr 16, 2012 at 10:51 PM, 陳韋任 wrote:
>> what does the inline sequence look like ? what kind of things (other
>> than refill tlb) performed in callout but not the inlined sequence ?
>
> What do you mean by the inline sequence, the host binary? If so,
>
> ---
> 0xe86c8
> mov_i32 tmp2
Le samedi 21 avril 2012 à 08:08 +0200, Andreas Färber a écrit :
> Am 15.04.2012 05:10, schrieb Andreas Färber:
> > Hello,
> >
> > This series splits up my m68k QOM'ification patch from the qom-cpu-others
> > RFC series.
> > CPU models are now modelled as subclasses with their own initfns, leaving
Le dimanche 22 avril 2012 à 01:17 +0200, Laurent Vivier a écrit :
> Le samedi 21 avril 2012 à 08:08 +0200, Andreas Färber a écrit :
> > Am 15.04.2012 05:10, schrieb Andreas Färber:
> > > Hello,
> > >
> > > This series splits up my m68k QOM'ification patch from the qom-cpu-others
> > > RFC series.
Hi qemuers,
I am a qemu user.
I am using qemu to run VMs on my computer with amd chip on board.
However, my computer doesn't support amd-v, so the performance of the VM is low.
I do have experiences in optimization of program using sse technique.
Is it possible to speed up the qemu for those x86
> I am using qemu to run VMs on my computer with amd chip on board.
> However, my computer doesn't support amd-v, so the performance of the VM is
> low.
> I do have experiences in optimization of program using sse technique.
> Is it possible to speed up the qemu for those x86 chips that do not sup
35 matches
Mail list logo
