> do we have some clear instructions about how to set the whole thing up using
> the latest publicly available code? (Which patches to apply, in which order
> etc)?
>
> Btw these instructions could go in the dedicated MTTCG wiki page of QEMU as
> well I guess..
Hi Claudio,
You can find mttcg +
On 7 September 2015 at 16:37, Andrew Jones wrote:
> +SHELL := /bin/bash
This indeed fixed the issue.
Thanks.
On 4 September 2015 at 16:05, Andrew Jones wrote:
> This doesn't reproduce for me. I did the following, and it worked
> fine.
>
> make distclean
> ./configure --arch=arm --cross-prefix=arm-linux-gnu-
> make
> ./configure --arch=arm64 --cross-prefix=aarch64-linux-gnu-
> make clean && make
Ok I thi
On 4 September 2015 at 16:05, Andrew Jones wrote:
> This doesn't reproduce for me. I did the following, and it worked
> fine.
>
> make distclean
> ./configure --arch=arm --cross-prefix=arm-linux-gnu-
> make
> ./configure --arch=arm64 --cross-prefix=aarch64-linux-gnu-
> make clean && make
This is
On 4 September 2015 at 12:48, Andrew Jones wrote:
> The lines this
> patch adds are already there. See the arm_clean target in
> config/config-arm-common.mak.
I see your point now. Maybe then "arm_clean" should be changed in
"arch_clean" in config-arm-common.mak?
Regards.
On 4 September 2015 at 12:48, Andrew Jones wrote:
> Are you also running configure (with the opposite arch selected) after
> 'make clean'? If not, then that could be the source of your problems.
> Anyway, please describe the issues you're seeing because I don't see
> what this patch is doing that
Properly clean any generated object and binary files after a 'make clean',
this fixes an issue when trying to reconfigure between arm and arm64.
Signed-off-by: Alexander Spyridakis
---
config/config-arm.mak | 2 ++
config/config-arm64.mak | 3 ++-
2 files changed, 4 insertions(+),
Basic torture test that continuously modifies a single instruction
opcode and checks if all modifications were done and run as expected.
Signed-off-by: Alexander Spyridakis
---
arm/self-modifying-test.c| 109 +++
config/config-arm-common.mak | 2
The test case is meant for testing the new mttcg implementation, although it was
also verified on KVM targets like Arndale and OMAP5-uevm for ARMv7 and the Juno
board (aarch32 and aarch64 guests) for ARMv8.
Alexander Spyridakis (2):
arm/arm64: Add self-modifying code test
arm/arm64 c
On 23 July 2015 at 12:04, Andrew Jones wrote:
> One more observation; to make this work for aarch64 you'll need to modify
> your instruction modification. The add immediate can't be changed with
> +-1 like it can for arm. Please make sure the code works for both, even
> if you need to do
>
> #ifde
Hello Andrew,
First, thanks for the comments.
On 22 July 2015 at 14:38, Andrew Jones wrote:
> I took a quick look at this and see issues with the test code. First,
> you're spinning on a stack variable with this,
>
> /* Wait for our turn */
> while(next_cpu != cpu);
>
> next_cpu needs to
Hello all,
You can find a new self-modifying test case in the following branch:
> git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git -b
> smc_test
For each core, the test will run a small assembly snippet which
increments a variable. Immediately after, the snippet is modifi
On 25 June 2015 at 18:01, Frederic Konrad wrote:
> I just tested this with vexpress, seems ATOMIC is not defined by default it
> uses:
Wow nice catch! Somehow between revision the define was no longer
propagated and ATOMIC was not defined at all.
Tested with 8 cores and no more errors. As you sa
On 24 June 2015 at 17:34, Alex Bennée wrote:
> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
> leaving one CPU spinning forever waiting for the second CPU to wake up.
> We simply need to poke the halt_cond once we have processed the PSCI
> power on call.
Thanks Alex. Wor
Hello all,
You can find the latest tcg atomic test payload in the following repo:
> git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git
You also need an arm baremetal cross-compiler like arm-none-gnueabi- (arm)
and the usual aarch64-linux-gnu- (arm64). Due to a PSCI bug in th
Hello Paolo,
On 7 May 2015 at 14:55, Paolo Bonzini wrote:
>> For the example spinlock test, racing errors could not be reproduced in
>> the default single-threaded TCG, even with a non-atomic lock. In KVM the
>> expected behaviour of no errors with regular locks, and some errors with
>> a non-ato
Hi Andrew,
On 11 May 2015 at 12:17, Andrew Jones wrote:
> > +
> > +void atomic_lock(int *lock_var)
> > +{
> > +while (__sync_lock_test_and_set(lock_var, 1));
> > +}
> > +
> > +void atomic_unlock(int *lock_var)
> > +{
> > +__sync_lock_release(lock_var);
> > +}
>
> Do these builtins actuall
similar manner this test is standalone and not part of 'make check'.
Suggested-by: Jani Kokkonen
Suggested-by: Claudio Fontana
Signed-off-by: Alexander Spyridakis
---
tests/atomic-test/Makefile | 63 ++
tests/atomic-test/helpers.c | 84
te
Signed-off-by: Alexander Spyridakis
---
tests/atomic-test/Makefile | 3 +++
tests/atomic-test/helpers.c | 21 +
tests/atomic-test/helpers.h | 12
tests/atomic-test/main.c| 35 ++-
tests/atomic-test/printf.c | 5 +
5 files
lock was observed. Next steps are to test multi-threaded TCG
with this kind of payloads, extend the infrastructure to more complex and
sensitive test cases, as well as support different architectures.
This work has been sponsored by Huawei Technologies Dusseldorf GmbH.
Alexander Spyridak
On Mon, Feb 16, 2015 at 2:43 PM, Jan Kiszka wrote:
> Hi,
>
> next issue related to KVM/QEMU on the TK1: The guest image I'm running
> gives proper framebuffer output when in emulation mode. Once KVM is
> enabled, the screen is - at best - only initially updated. Sometimes I
> see the famous tux im
on the Juno board with an ARMv7 bare metal binary and it
worked as expected.
Thanks.
Tested-by: Alexander Spyridakis
Hello,
Is this call still going to happen today? I haven't yet received the
contact details.
Thanks and best regards.
On 6 November 2014 14:44, Peter Maydell wrote:
>
>
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
>
> The plan for providing ACPI to guests is that we run a UEFI BIOS
>
system devices/peripherals
- FACS: Needs to be pointed from FADT
Signed-off-by: Alexander Spyridakis
Signed-off-by: Alvise Rigo
---
hw/arm/Makefile.objs | 2 +-
hw/arm/virt-acpi.c | 84 ++
include/hw/arm/virt-acpi.h | 52 +
subtables are used to define the GIC regions.
Signed-off-by: Alexander Spyridakis
---
hw/arm/virt-acpi.c | 65 +---
include/hw/acpi/acpi-defs.h | 73 -
include/hw/arm/virt-acpi.h | 6
3 files changed
- NAND Flash
- virtio-mmio
Signed-off-by: Alexander Spyridakis
---
hw/arm/virt-acpi.c | 284 +++-
include/hw/acpi/acpi-defs.h | 34 ++
include/hw/arm/virt-acpi.h | 9 ++
3 files changed, 325 insertions(+), 2 deletions(-)
diff --git a/hw/arm
The ACPI related header file acpi-defs.h, includes definitions that
apply on other architectures as well. Move it in `include/hw/acpi/`
to sanely include it from other architectures.
Signed-off-by: Alvise Rigo
---
hw/i386/acpi-build.c| 2 +-
hw/i386/acpi-defs.h | 368 --
build 5206 and
the Juno development board. For kernel and driver support it is based
on the "Introduce ACPI for ARM64 based on ACPI 5.1" and
"Drivers for Juno to boot from ACPI" patch series from Hanjun Guo.
Alexander Spyridakis (7):
hw/i386: Move ACPI header definitions in
Expose the needed device information to the table generation
insfrastructure and assemble the final compacted ACPI binary
blob in the guest memory.
Signed-off-by: Alvise Rigo
---
hw/arm/boot.c| 26 +
hw/arm/virt-acpi.c | 18 +-
hw/arm/virt.c
FADT and FACS taking into account
the new additions of ACPI v5.1 in `include/hw/acpi/acpi-defs.h`
Signed-off-by: Alexander Spyridakis
Signed-off-by: Alvise Rigo
---
hw/arm/virt-acpi.c | 41 +++--
include/hw/acpi/acpi-defs.h | 141 ++--
2
being FACS and DSDT which
are pointed from FADT).
Finally implement a common header and checksum helper functions
for usage in all generated ACPI tables.
Signed-off-by: Alexander Spyridakis
Signed-off-by: Alvise Rigo
---
hw/arm/virt-acpi.c | 93
On 29 June 2013 21:20, Peter Maydell wrote:
> So this is enabling support for emulating 32 bit VMs with a
> QEMU running as a 64 bit process, but the commit message
> doesn't mention this. Did you test that combination?
Nope, this case is not handled. Currently it won't crash but of course
won't
On 29 June 2013 21:24, Peter Maydell wrote:
> On 28 June 2013 13:11, Mian M. Hamayun
> wrote:
>> From: Alexander Spyridakis
>>
>> AArch64 uses a cpu-release-addr memory location (defined in the dts) as
>> a way to inform secondary CPUs where to jump to and enter
On 29 June 2013 21:21, Peter Maydell wrote:
> On 28 June 2013 13:11, Mian M. Hamayun
> wrote:
> > From: "Mian M. Hamayun"
> >
> > The vexpress model for A57 is based on the A15 machine model with a few
> > changes in the daughterboard initialization (using a subset of A15
> > functionality). Th
On 29 June 2013 21:17, Peter Maydell wrote:
>
> > +#ifdef TARGET_AARCH64
> > +int kvm_arch_init_vcpu(CPUState *cs)
> > +{
> > +struct kvm_vcpu_init init;
> > +int ret;
> > +
> > +/* Try initializing with Foundation Models */
> > +init.target = KVM_ARM_TARGET_FOUNDATION_V8;
> > +
On 24 January 2013 19:57, Peter Maydell wrote:
> It appears to be one of the reasons. The other is that
> the kernel is trashing the device tree because it
> happens to be sitting in the same page as the last
> part-page of the initrd, and free_initrd_mem() rounds
> up to a page boundary when poi
37 matches
Mail list logo
