I'm trying to debug why TCI doesn't work for the Microblaze example at
http://wiki.qemu.org/Testing. My debug led me to the return addresses
for exceptions being too far forward and this adjustment looked
related so I gave this change a shot, and it works!
I did some further-afield image testing,
On 8/16/15 09:41, Chen Gang wrote:
> On 8/16/15 02:16, Chen Gang wrote:
>>
>> On 8/15/15 23:47, Richard Henderson wrote:
>>> On Aug 15, 2015 2:56 AM, Chen Gang
Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
insns also can be mixed together! The related C code,
Ping!
On Sat, Jul 11, 2015 at 6:59 PM, Peter Crosthwaite
wrote:
> From: Peter Crosthwaite
>
> Move the target_disas() s390 specifics to the QOM disas_set_info hook
> and delete the #ifdef specific code in disas.c.
>
> Cc: Richard Henderson
> Cc: Alexander Graf
> Signed-off-by: Peter Crosthwait
Ping!
On Sat, Jul 11, 2015 at 7:00 PM, Peter Crosthwaite
wrote:
> From: Peter Crosthwaite
>
> Move the target_disas() alpha specifics to the QOM disas_set_info hook
> and delete the #ifdef specific code in disas.c.
>
> This also makes monitor_disas() consistent with target_disas(), as
> monitor_
Ping!
This rebases cleanly following the unfreeze.
Regards,
Peter
On Sun, Jul 12, 2015 at 5:18 AM, Andreas Färber wrote:
> Am 12.07.2015 um 03:59 schrieb Peter Crosthwaite:
>> Continue QOMifying target-specific disassembly. Convert all arches except for
>> X86 and PPC. They will be round 3 and
On 8/16/15 02:16, Chen Gang wrote:
>
> On 8/15/15 23:47, Richard Henderson wrote:
>> On Aug 15, 2015 2:56 AM, Chen Gang
>>> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
>>> insns also can be mixed together! The related C code, -save-temps, and
>>> objdump files are i
From: Peter Crosthwaite
The bootloader can just pass EM_S390 directly, as that
is architecture specific code.
This removes another architecture specific definition from the global
namespace.
Cc: Richard Henderson
Cc: Alexander Graf
Signed-off-by: Peter Crosthwaite
---
hw/s390x/ipl.c | 4
From: Peter Crosthwaite
The bootloaders can just pass EM_XTENSA directly, as that
is architecture specific code.
This removes another architecture specific definition from the global
namespace.
Cc: Max Filippov
Signed-off-by: Peter Crosthwaite
---
hw/xtensa/sim.c | 4 ++--
hw/xtensa/xtfp
On Sat, Jul 18, 2015 at 5:33 AM, Paolo Bonzini wrote:
>
>
> On 18/07/2015 11:40, Peter Crosthwaite wrote:
>> From: Peter Crosthwaite
>>
>> The only generic code relying on this is linux-user. Linux user already
>> has a lot of #ifdef TARGET_ customisation so just define ELF_MACHINE
>> locally the
From: Peter Crosthwaite
The bootloader can just pass EM_TRICORE directly, as that
is architecture specific code.
This removes another architecture specific definition from the global
namespace.
Cc: Bastian Koppelmann
Signed-off-by: Peter Crosthwaite
---
hw/tricore/tricore_testboard.c | 2 +-
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
The bootloaders can just pass EM_MIPS directly, as that is
architecture specific code.
This removes another architecture specif
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
The bootloader can just pass EM_OPENRISC directly, as that is
architecture specific code.
This removes another architecture spe
From: Peter Crosthwaite
The bootloaders can just pass EM_SPARC or EM_SPARCV9 directly, as
they are architecture specific code (to one or the other).
This removes another architecture specific definition from the global
namespace.
Cc: Mark Cave-Ayland
Signed-off-by: Peter Crosthwaite
---
hw/s
From: Peter Crosthwaite
The bootloader can just pass EM_MOXIE directly, as that is architecture
specific code.
This removes another architecture specific definition from the global
namespace.
Cc: Anthony Green
Signed-off-by: Peter Crosthwaite
---
hw/moxie/moxiesim.c | 2 +-
target-moxie/cpu.
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
This removes another architecture specific definition from the global
namespace.
Cc: Aurelien Jarno
Signed-off-by: Peter Crost
From: Peter Crosthwaite
Rename ELF_MACHINE to be PPC specific. This is used as-is by the
various PPC bootloaders and is locally defined to ELF_MACHINE in linux
user in PPC specific ifdeffery.
This removes another architecture specific definition from the global
namespace (as desired by multi-arc
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
This removes another architecture specific definition from the global
namespace.
Cc: Guan Xuetao
Signed-off-by: Peter Crosthwa
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux-users'
default behaviour or setting ELF_MACHINE to ELF_ARCH will handle this.
The microblaze bootloader can just pass EM_MICROBLAZE directly, as that
is architecture specific code.
This removes another archit
From: Peter Crosthwaite
Rename ELF_MACHINE to be I386 specific. This is used as-is by the
multiboot loader.
Linux-user previously used this definition but will not anymore,
falling back to the default bahaviour of using ELF_ARCH as ELF_MACHINE.
This removes another architecture specific definit
From: Peter Crosthwaite
ELF_MACHINE is unused by target alpha.
Cc: Richard Henderson
Signed-off-by: Peter Crosthwaite
---
target-alpha/cpu.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h
index 91c56d6..2ca8dbe 100644
--- a/target-alpha/cpu.h
+++
Every arch defines ELF_MACHINE in cpu.h to an arch-specific value. This
definition is rarely needed by core code (only in a few cases). It
conflicts with the multi-arch effort where cpu.h cannot export cpu
specifics via macros like this. So remove ELF_MACHINE completely from
all the cpu.h's.
Linux
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
The machine model bootloaders can just pass EM_68K directly, as that
is architecture specific code.
This removes another archit
For many arch's this macro is defined as the predicatable behaviour
of checking the argument for eqaulity against ELF_ARCH. Provide a
default define as such, so only archs with special handling (usually
allowing multiple EM values) need to provide a def.
Arches that do any of:
1: provide this def
From: Peter Crosthwaite
The only generic code relying on this is linux-user, but linux users'
default behaviour of defaulting ELF_MACHINE to ELF_ARCH will handle
this.
The bootloader can just pass EM_CRIS directly, as that is architecture
specific code.
This removes another architecture specifi
In most (but not all) cases, ELF_MACHINE and ELF_ARCH are safely the
same. Default ELF_MACHINE to ELF_ARCH. This makes defining ELF_MACHINE
optional for target-*/cpu.h when they are known to match.
Signed-off-by: Peter Crosthwaite
---
linux-user/elfload.c | 4
1 file changed, 4 insertions(+
From: Peter Crosthwaite
The only generic code relying on this is linux-user. Linux user
already has a lot of #ifdef TARGET_ customisation so instead, define
ELF_ARCH as either EM_ARM or EM_AARCH64 appropriately.
The armv7m bootloader can just pass EM_ARM directly, as that
is architecture specifi
same with kvm clock:
[0.195073] Switched to clocksource kvm-clock
[0.195509] [ cut here ]
[0.195509] WARNING: CPU: 1 PID: 1 at kernel/time/tick-sched.c:192
can_stop_full_tick+0x1c1/0x200()
[0.195515] NO_HZ FULL will not work with unstable sched clock
[
On 15 August 2015 at 22:18, Peter Crosthwaite
wrote:
> This has come up a few times, and the conclusion was to do the
> inlining by preference. I vaguely remember PMM started an effort to
> build infrastructure to hide the internals from use by outsiders, but
> the struct def is desirable for the
On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
wrote:
> Connect the Sysbus AHCI device to ZynqMP.
>
> Signed-off-by: Alistair Francis
> Reviewed-by: Sai Pavan Boddu
> ---
> hw/arm/xlnx-zynqmp.c | 20
> include/hw/arm/xlnx-zynqmp.h |3 +++
> 2 files changed
On Sat, Aug 15, 2015 at 2:21 PM, Peter Crosthwaite
wrote:
> On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
> wrote:
>> Pull the AHCI state structure out into the header. This allows
>> other containers to access the struct. This is required to add
>> the device to modern SoC containers.
>>
>>
On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
wrote:
> If the ObjectClass has no type return NULL instead of trying to compare
> the type name.
>
What was the issue?
Regards,
Peter
> Signed-off-by: Alistair Francis
> Reviewed-by: Sai Pavan Boddu
> ---
> qom/object.c |2 +-
> 1 files
On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
wrote:
> Pull the AHCI state structure out into the header. This allows
> other containers to access the struct. This is required to add
> the device to modern SoC containers.
>
> Signed-off-by: Alistair Francis
> Reviewed-by: Sai Pavan Boddu
>
On Wed, Jul 29, 2015 at 5:12 PM, Alistair Francis
wrote:
> On Wed, Jul 29, 2015 at 3:21 PM, John Snow wrote:
>>
>>
>> On 07/27/2015 02:37 PM, Alistair Francis wrote:
>>> Pull the AHCI state structure out into the header. This allows
>>> other containers to access the struct. This is required to a
Is there a functional reason for making this change, or pure
organisational? Either way the patch is ok, I'm just looking for the
motivation as this stuff did pop up in the multi-arch refactorings at
one stage and I did think about moving it. Can we add a one-liner to
commit message?
Regards,
Pete
Am 14.08.2015 um 16:45 schrieb Peter Lieven:
> Am 14.08.2015 um 16:08 schrieb Kevin Wolf:
>> Am 14.08.2015 um 15:43 hat Peter Lieven geschrieben:
>>> Am 22.06.2015 um 23:54 schrieb John Snow:
On 06/22/2015 09:09 AM, Peter Lieven wrote:
> Am 22.06.2015 um 11:25 schrieb Stefan Hajnoczi:
qemu currently limits the space for the evironment and arguments to
32 * PAGE_SIZE. Linux limits the argument space to 1/4 of the stack size.
A program trying to detect this with a getrlimit(RLIMIT_STACK) syscall
will typically get a much larger limit than qemus current 128kB.
The current limit ca
Build environments often invoke commands with huge argument lists.
For native builds, the limit on current linux (>2.6.33) is 1/4th
of the stack size, typically 2MByte, so this works fine.
For chroots with qemu emulation, the limit currently is set by
MAX_ARG_PAGES, i.e. 32*4kByte.
Without the pa
Hi,
while switching to a FULL tickless kernel i detected that all our VMs
produce the following stack trace while running under qemu 2.3.0.
[0.195160] HPET: 3 timers in total, 0 timers will be used for
per-cpu timer
[0.195181] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0
[0.195188] hpet0:
On 8/15/15 23:47, Richard Henderson wrote:
> On Aug 15, 2015 2:56 AM, Chen Gang
>> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
>> insns also can be mixed together! The related C code, -save-temps, and
>> objdump files are in attachments (is it gcc's issue? I guess n
On Aug 15, 2015 2:56 AM, Chen Gang
> Oh, we are unlucky, after continue gcc testsuite, add/sub floating point
> insns also can be mixed together! The related C code, -save-temps, and
> objdump files are in attachments (is it gcc's issue? I guess not).
>
> So, I guess, we have to 'crack' all flo
Public bug reported:
I'm using Fedora 22.
Firstly, what works:
A single VM instance, running Windows. Although, I am keeping this (GTK) window
focused.
What really fails:
If I have two running VM's, WIndows XP and Windows Vista:
1. I press Ctrl-Alt-G to get the focus.
2. That works first time.
On 15/08/2015 11:57, Pavel Dovgalyuk wrote:
> Hi, Paolo!
>
> Will you apply these patches to 2.5?
>
Yes, I'll put them in my next pull request.
Paolo
Hi, Paolo!
Will you apply these patches to 2.5?
Pavel Dovgalyuk
Sent using CloudMagic
[https://cloudmagic.com/k/d/mailapp?ct=ta&cv=5.1.11.3&pv=4.4.2]
On вт, Авг 04, 2015 at 11:43 AM, Pavel Dovgalyuk < pavel.dovga...@ispras.ru
[pavel.dovga...@ispras.ru] > wrote:
This set of patches is relat
On 8/13/15 22:59, Chen Gang wrote:
> Hello all:
>
> For me, I guess for single insns, they are simple, and each calculation
> insns group can not be mixed with each other. So current implementation
> should be OK.
>
> For double insns, I guess, only mul calculation can be mixed with other
> calcu
44 matches
Mail list logo
