On 28/09/2014 18:33, Juan Quintela wrote:
Hi
Please, send any topic that you are interested in covering.
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every two weeks
By popular demand, a google calendar public entry with it
https://www.google.com/calendar/embed?src=dG9iMXRqcXAz
On 10/06/2014 08:20, Amit Shah wrote:
On (Fri) 16 May 2014 [17:00:37], fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This fixes a bug where qemu_icount and qemu_icount_bias are not migrated.
It adds a subsection "timer/icount" to vmstate_timers so icount is migrated only
when needed.
On 18/07/2013 17:35, Paolo Bonzini wrote:
Il 18/07/2013 17:06, Peter Maydell ha scritto:
On 18 July 2013 16:02, wrote:
As I said in the last email, we have issues with determinism with icount.
We are wondering if determinism is really ensured with icount?
My opinion is that it *should* be det
On 29/07/2013 18:42, Paolo Bonzini wrote:
Il 29/07/2013 17:27, Frederic Konrad ha scritto:
On 18/07/2013 17:35, Paolo Bonzini wrote:
Il 18/07/2013 17:06, Peter Maydell ha scritto:
On 18 July 2013 16:02, wrote:
As I said in the last email, we have issues with determinism with
icount.
We are
On 19/03/2014 16:48, Stefan Hajnoczi wrote:
This RFC is just the beginning. The same problem exists for virtio-net and
other devices. I am looking for feedback before I convert all of virtio.
The virtio transport/device split is broken as follows:
1. The virtio-blk device is never finalized b
On 22/10/2014 13:38, Pavel Dovgalyuk wrote:
Hi Pavel,
This patch fixes instructions counting when execution is stopped on
breakpoint (e.g. set from gdb). Without a patch extra instruction is translated
and icount is incremented by invalid value (which equals to number of
executed instructions +
On 23/10/2014 07:57, Pavel Dovgaluk wrote:
From: Frederic Konrad [mailto:fred.kon...@greensocs.com]
On 22/10/2014 13:38, Pavel Dovgalyuk wrote:
Hi Pavel,
This patch fixes instructions counting when execution is stopped on
breakpoint (e.g. set from gdb). Without a patch extra instruction is
On 23/10/2014 09:52, Pavel Dovgaluk wrote:
From: Frederic Konrad [mailto:fred.kon...@greensocs.com]
On 23/10/2014 07:57, Pavel Dovgaluk wrote:
From: Frederic Konrad [mailto:fred.kon...@greensocs.com]
On 22/10/2014 13:38, Pavel Dovgalyuk wrote:
Hi Pavel,
This patch fixes instructions counting
On 01/09/2014 18:22, Paolo Bonzini wrote:
Il 03/07/2014 16:33, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
Hi everybody,
This is the sixth version of this RFC (see the changes below).
Those are the two first patch-set we have been worked on for reverse execution.
The first p
On 08/09/2014 09:57, Frederic Konrad wrote:
On 01/09/2014 18:22, Paolo Bonzini wrote:
Il 03/07/2014 16:33, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
Hi everybody,
This is the sixth version of this RFC (see the changes below).
Those are the two first patch-set we have been
On 08/09/2014 10:29, Paolo Bonzini wrote:
Il 08/09/2014 10:09, Frederic Konrad ha scritto:
By the way how do you want to have this discussion?
At the KVM forum? Or by phone on KVM phone call?
Or both. :)
Seriously, Pavel is presenting on record/replay at KVM Forum. I guess
there will be
On 09/09/2014 08:30, Pavel Dovgaluk wrote:
From: Frederic Konrad [mailto:fred.kon...@greensocs.com]
On 08/09/2014 10:29, Paolo Bonzini wrote:
Il 08/09/2014 10:09, Frederic Konrad ha scritto:
By the way how do you want to have this discussion?
At the KVM forum? Or by phone on KVM phone call
On 16/07/2014 05:48, Peter Crosthwaite wrote:
On Wed, Jul 16, 2014 at 1:18 AM, wrote:
From: KONRAD Frederic
This checks that s->chr is not NULL before using it.
Signed-off-by: KONRAD Frederic
---
hw/char/cadence_uart.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(
On 17/07/2014 11:45, Peter Maydell wrote:
So we just released rc2. The proposed schedule has
rc3 next Tuesday, with final release the Tuesday after.
My thought is that we should aim for rc3 to add only
a fairly small number of focussed and "safe" bugfixes,
with the intention of making the final
On 17/07/2014 13:01, Pavel Dovgalyuk wrote:
This set of patches is related to the reverse execution and deterministic
replay of qemu execution Our implementation of deterministic replay can
be used for deterministic and reverse debugging of guest code through gdb
remote interface.
Execution rec
On 30/07/2014 11:25, Paolo Bonzini wrote:
Il 30/07/2014 09:44, Pavel Dovgaluk ha scritto:
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
- patch 16 should also use subsections, and perhaps apply to all other
CPUs too?
We implemented replay only for i386 and A
On 30/07/2014 15:35, Paolo Bonzini wrote:
Il 30/07/2014 15:19, Frederic Konrad ha scritto:
Start by submitting only the icount-based
implementation, the other can come later.
Paolo
Hi all,
I think that's actually our implementation cover no?
(http://lists.gnu.org/archive/html/qemu-devel
On 30/07/2014 16:51, Frederic Konrad wrote:
On 30/07/2014 15:35, Paolo Bonzini wrote:
Il 30/07/2014 15:19, Frederic Konrad ha scritto:
Start by submitting only the icount-based
implementation, the other can come later.
Paolo
Hi all,
I think that's actually our implementation cover no?
On 22/03/2014 09:57, Paolo Bonzini wrote:
Il 21/03/2014 20:17, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
This fixes a bug where qemu_icount and qemu_icount_bias are not
migrated.
Signed-off-by: KONRAD Frederic
---
cpus.c | 23 ++-
1 file changed, 22 i
On 21/03/2014 20:54, Dr. David Alan Gilbert wrote:
* fred.kon...@greensocs.com (fred.kon...@greensocs.com) wrote:
From: KONRAD Frederic
This makes qemu_savevm_state public for reverse-execution.
It's interesting that you're doing this repetitive snapshot;
in some ways it's similar to Michael
On 24/03/2014 16:42, Paolo Bonzini wrote:
Il 24/03/2014 15:49, Frederic Konrad ha scritto:
--- a/cpus.c
+++ b/cpus.c
@@ -427,6 +427,26 @@ void qemu_clock_warp(QEMUClockType type)
}
}
+static bool icount_state_needed(void *opaque)
+{
+return (use_icount != 0);
+}
+
+/*
+ * This is a
Hi everybody,
I didn't see anything on the list about that.
I get this bug in the current git.
I configured qemu with the following command line:
./configure --target-list=ppc-softmmu
I ran QEMU with the following command line:
./ppc-softmmu/qemu-system-ppc --M mpc8544ds
I get this segfault:
On 31/03/2014 13:30, Gerd Hoffmann wrote:
On Fr, 2014-03-28 at 15:37 +0100, Frederic Konrad wrote:
Hi everybody,
I didn't see anything on the list about that.
I get this bug in the current git.
I configured qemu with the following command line:
./configure --target-list=ppc-softmmu
Hi everybody,
I tried to boot a mpc85xx smp image with a new platform inside qemu.
This command line reproduce the issue:
./ppc-softmmu/qemu-system-ppc -M mpc8544ds -kernel zImage --smp 2
This use to work but since this commit:
d197fdbc3b83655f3c145722805f0998c04dce16
target-ppc: Reset SPRs o
On 03/04/2014 17:29, Andreas Färber wrote:
Hi Fred,
Am 03.04.2014 17:19, schrieb Frederic Konrad:
I tried to boot a mpc85xx smp image with a new platform inside qemu.
This command line reproduce the issue:
./ppc-softmmu/qemu-system-ppc -M mpc8544ds -kernel zImage --smp 2
This use to work but
, fixing e500v2 SMP boot.
Reported-by: Frederic Konrad
Signed-off-by: Alexander Graf
Tested-by: KONRAD Frederic
Thanks,
Fred
---
hw/ppc/e500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index d7ba25f..f984b3e 100644
--- a/hw/ppc/e500.c
On 12/12/2013 01:09, Sean Xie wrote:
Hi all,
Recently I am struggling in examing the effect of host kernel I/O
stacks on high-speed SSD, especially the new PCIe SSD, without
the availability of the necessary hardware. After several reading
online I found out QEMU+SystemC model environment mig
Hi Paolo,
This looks ok, but I don't find the branch where it applies?
Seems it's already fixed on master.
Thanks,
Fred
On 14/10/2013 18:23, Paolo Bonzini wrote:
We do not need to access vdev on the MSI-X fast path of virtio_pci_notify.
Signed-off-by: Paolo Bonzini
---
It is possibl
On 11/02/2015 04:33, Alex Bennée wrote:
Frederic Konrad writes:
Hi everybody,
In multithread tlb_flush is broken as CPUA can flush an other CPUB and
CPUB can be
executing code, and fixing this can be quite hard:
* We need to exit the CPU which is flushed.
* Makes sure the CPU is
On 11/02/2015 09:42, Frederic Konrad wrote:
On 11/02/2015 04:33, Alex Bennée wrote:
Frederic Konrad writes:
Hi everybody,
In multithread tlb_flush is broken as CPUA can flush an other CPUB and
CPUB can be
executing code, and fixing this can be quite hard:
* We need to exit the CPU which
On 27/01/2015 15:45, Alex Bennée wrote:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
We need a different TranslationBlock list for each core in case of multithread
TCG.
Signed-off-by: KONRAD Frederic
---
translate-all.c | 40 ++--
1 file cha
Hi,
I wondering how we can have one TCGContext per thread cleanly.
We should be able to do this:
diff --git a/tcg/tcg.h b/tcg/tcg.h
index baf053a..8d488dc 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -533,7 +533,7 @@ struct TCGContext {
struct TCGBackendData *be;
};
-extern TCGContext tcg_c
On 28/01/2015 16:17, Paolo Bonzini wrote:
On 28/01/2015 16:04, Frederic Konrad wrote:
/* code generation context */
-TCGContext tcg_ctx;
+__thread TCGContext tcg_ctx;
But the big problem is the initialisation, it's done only onetime in the
iothread with
the accelerator..
You need to
On 30/01/2015 11:26, Marc Marí wrote:
El Fri, 30 Jan 2015 08:37:47 +0100
Jan Kiszka escribió:
On 2015-01-30 00:06, Paolo Bonzini wrote:
On 29/01/2015 20:37, Marc Marí wrote:
Is this an expected behaviour? I can't see why.
I'd like to know if there is a certain reason why it doesn't work.
Or
On 29/01/2015 16:17, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time in case of
TCG multithread.
Signed-off-by: KONRAD Frederic
Hi Peter,
All the same comments I had on this patch earlier
On 29/01/2015 16:24, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
We need a different TranslationBlock list for each core in case of multithread
TCG.
Signed-off-by: KONRAD Frederic
---
translate-all.c | 40 ++--
1 fil
On 29/01/2015 16:25, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
spinlock is only used in two cases:
* cpu-exec.c: to protect TranslationBlock
* mem_helper.c: for lock helper in target-i386 (which seems broken).
It's a pthread_mutex_t in user-mode so
On 29/01/2015 16:52, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
This removes exit_request global and adds a variable in CPUState for this.
Only the flag for the first cpu is used for the moment as we are still with one
TCG thread.
--- a/cpus.c
+++ b/cpus.c
Hi everybody,
In multithread tlb_flush is broken as CPUA can flush an other CPUB and
CPUB can be
executing code, and fixing this can be quite hard:
* We need to exit the CPU which is flushed.
* Makes sure the CPU is stopped.
* Then we can flush tlb.
The big issues are:
* Two threads can
Hi,
Yes a v2 will come soon.
Actually I'm trying to unbreak GDB stub and a strange segfault with smp > 2.
Fred
On 27/03/2015 11:08, Alex Bennée wrote:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
Hi everybody,
This is the start of our work on TCG multithread.
It's been a while
Hi everybody and happy new year,
I wondered what is the goal of tb_lock in cpu-exec.c.
According to the exec-all.h it's to protect tbs and page table but why do we
have to cover the whole cpu_exec function?
I'm asking this because we planned to reuse tb_lock to protect every
access to
tb_ctx
Hi everybody,
In case of multithread TCG what is the best way to handle qemu_global_mutex?
We though to have one mutex per vcpu and then synchronize vcpu threads when
they exit (eg: in tcg_exec_all).
Is that making sense?
Thanks,
Fred
On 15/01/2015 11:34, Peter Maydell wrote:
On 15 January 2015 at 10:25, Frederic Konrad wrote:
Hi everybody,
In case of multithread TCG what is the best way to handle qemu_global_mutex?
It shouldn't need any changes I think. You're basically bringing
TCG into line with what KVM a
On 15/01/2015 12:12, Paolo Bonzini wrote:
[now with correct listserver address]
On 15/01/2015 11:25, Frederic Konrad wrote:
Hi everybody,
In case of multithread TCG what is the best way to handle
qemu_global_mutex?
We though to have one mutex per vcpu and then synchronize vcpu threads when
On 15/01/2015 13:56, Paolo Bonzini wrote:
On 15/01/2015 13:51, Frederic Konrad wrote:
Thanks for the reply.
As I understand the idea of Jan is to unlock the global_mutex during tcg
execution.
Is that right?
So that means it's currently not the case and we won't be able to run
two T
On 15/01/2015 12:14, Alexander Graf wrote:
On 15.01.15 12:12, Paolo Bonzini wrote:
[now with correct listserver address]
On 15/01/2015 11:25, Frederic Konrad wrote:
Hi everybody,
In case of multithread TCG what is the best way to handle
qemu_global_mutex?
We though to have one mutex per
On 16/01/2015 09:07, Jan Kiszka wrote:
On 2015-01-16 08:25, Mark Burton wrote:
On 15 Jan 2015, at 22:41, Paolo Bonzini wrote:
On 15/01/2015 21:53, Mark Burton wrote:
Jan said he had it working at least on ARM (MusicPal).
yeah - our problem is when we enable multi-threads - which I dont bel
On 07/11/2014 12:36, Pavel Dovgaluk wrote:
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
On 07/11/2014 11:32, Pavel Dovgalyuk wrote:
Replay uses number of executed instructions to determine corrent events
injection moments. This patch introduces new function for querying the
instructions coun
Hi everybody,
Here is the plan we will follow:
We will be focusing - from the outset - on the end goal of multi-threaded TCG
in full system emulation mode. On the way, we expect this will ‘fix’ user mode.
The plan is:
* Create one cache per CPU as a first step. We can do more next and share a
On 16/12/2014 10:31, Paolo Bonzini wrote:
On 16/12/2014 10:13, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time in case of
TCG multithread.
Signed-off-by: KONRAD Frederic
---
target-arm/cpu.c | 15 +++
On 16/12/2014 10:49, Paolo Bonzini wrote:
On 16/12/2014 10:36, Frederic Konrad wrote:
On 16/12/2014 10:31, Paolo Bonzini wrote:
On 16/12/2014 10:13, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time
in case of
TCG
On 16/12/2014 17:37, Peter Maydell wrote:
On 16 December 2014 at 09:13, wrote:
From: KONRAD Frederic
This adds a lock to avoid multiple exclusive access at the same time in case of
TCG multithread.
Hi Peter,
This feels to me like it's not really possible to review on
its own, since you ca
On 10/04/2015 18:03, Frederic Konrad wrote:
On 30/03/2015 23:46, Peter Maydell wrote:
On 30 March 2015 at 07:52, Mark Burton
wrote:
So - Fred is unwilling to send the patch set as it stands, because
frankly this part is totally broken.
There is an independent patch set that needs splitting
On 22/04/2015 15:18, Peter Maydell wrote:
On 22 April 2015 at 13:26, Frederic Konrad wrote:
[re summary of design]
Does that makes sense?
Oops, I think that I lost that email in the flow of stuff through the
mailing list. I think Alex is going to be doing the bulk of the review
on this for
On 23/04/2015 17:46, Alex Bennée wrote:
Alex Bennée writes:
Frederic Konrad writes:
Does that makes sense?
BTW here is the repository:
git clone g...@git.greensocs.com:fkonrad/mttcg.git -b multi_tcg_v4
Is there a non-authenticated read-only http or git:// access to this repo?
I should
Hi Emilio,
On 27/04/2015 19:06, Emilio G. Cota wrote:
Hi Fred,
On Wed, Apr 22, 2015 at 14:26:14 +0200, Frederic Konrad wrote:
git clone g...@git.greensocs.com:fkonrad/mttcg.git -b multi_tcg_v4
I've tried to run buildroot's vexpress-a9 with this, but unfortunately
it gets stuck befo
Hi Peter,
Thanks for your review.
On 14/05/2015 05:30, Peter Crosthwaite wrote:
On Wed, May 13, 2015 at 12:12 PM, wrote:
From: KONRAD Frederic
This adds the DP and the DPDMA to the Zynq MP.
Signed-off-by: KONRAD Frederic
---
hw/arm/xlnx-zynqmp.c | 23 +++
i
On 18/05/2015 09:34, Gerd Hoffmann wrote:
On Mi, 2015-05-13 at 21:12 +0200, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This allows to create a surface with a different format than xrgb.
What is the use case for this?
cheers,
Gerd
Hi,
The Display Port introduced in pat
+++ b/hw/dma/xilinx_dpdma.c
@@ -0,0 +1,1149 @@
+/*
+ * xilinx_dpdma.c
+ *
+ * Copyright (C) 2015 : GreenSocs Ltd
+ * http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ * Developed by :
+ * Frederic Konrad
+ *
+ * This program is free software; you can redistribute it and/or
On 18/05/2015 13:17, Gerd Hoffmann wrote:
On Mo, 2015-05-18 at 09:51 +0200, Frederic Konrad wrote:
On 18/05/2015 09:34, Gerd Hoffmann wrote:
On Mi, 2015-05-13 at 21:12 +0200, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This allows to create a surface with a different format than
/dpcd.c b/hw/display/dpcd.c
new file mode 100644
index 000..757b65e
--- /dev/null
+++ b/hw/display/dpcd.c
@@ -0,0 +1,139 @@
+/*
+ * dpcd.c
+ *
+ * Copyright (C)2015 : GreenSocs Ltd
+ * http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ * Developed by :
+ * Frederic Konrad
Hi Claudio,
I'll rebase soon tomorrow with a bit of luck ;).
Thanks,
Fred
On 07/10/2015 14:46, Claudio Fontana wrote:
> Hello Frederic,
>
> On 11.08.2015 08:27, Frederic Konrad wrote:
>> On 11/08/2015 08:15, Benjamin Herrenschmidt wrote:
>>> On Mon, 2015-0
On 29/10/2015 03:00, Peter Crosthwaite wrote:
> On Wed, Oct 28, 2015 at 10:32 AM, Alistair Francis <
> alistair.fran...@xilinx.com> wrote:
>
>> Connect the Xilinx SPI device to the ZynqMP model.
>>
>>
> "devices"
>
>
>> Signed-off-by: Alistair Francis
>> ---
>> V3:
>> - Expose the SPI Bus as part
ONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
>>
>> obj-$(CONFIG_PVPANIC) += pvpanic.o
>> obj-$(CONFIG_EDU) += edu.o
>> +obj-$(CONFIG_AUX) += aux.o
>> diff --git a/hw/misc/aux.c b/hw/misc/aux.c
>> new file mode 100644
>> index 000..bf300f7
>>
On 19/10/2015 06:09, Peter Crosthwaite wrote:
> Most of the control flow logic between send and recv (error checking
> etc) is the same. Factor this out into a common send_recv() API.
> This is then usable by clients, where the control logic for send
> and receive differs only by a boolean. E.g.
>
On 16/01/2016 01:33, Alistair Francis wrote:
> On Mon, Jan 4, 2016 at 10:25 AM, wrote:
>> From: KONRAD Frederic
>>
>> This is the 6th version of this patch-set of the implementation of the Xilinx
>> DisplayPort and DPDMA.
>>
>> This 6th version fixes some minors issues.
>>
>> Second patch introd
display/xlnx_dp.c
>> @@ -0,0 +1,1361 @@
>> +/*
>> + * xlnx_dp.c
>> + *
>> + * Copyright (C) 2015 : GreenSocs Ltd
>> + * http://www.greensocs.com/ , email: i...@greensocs.com
>> + *
>> + * Developed by :
>> + * Frederic Konrad
>> +
On 16/01/2016 02:50, Alistair Francis wrote:
> On Mon, Jan 4, 2016 at 10:25 AM, wrote:
>> From: KONRAD Frederic
>>
>> This adds the DP and the DPDMA to the Zynq MP platform.
>>
>> Signed-off-by: KONRAD Frederic
>> Reviewed-by: Peter Crosthwaite
>> Tested-By: Hyun Kwon
>> ---
>> hw/arm/xlnx-z
On 02/11/2015 10:09, Frederic Konrad wrote:
> On 19/10/2015 06:09, Peter Crosthwaite wrote:
>> Most of the control flow logic between send and recv (error checking
>> etc) is the same. Factor this out into a common send_recv() API.
>> This is then usable by clients, where
Hi,
Is there a git tree with this series somewhere?
Looks nice.
Thanks,
Fred
On 14/01/2016 11:55, Peer Adelt wrote:
> Hey guys :)
>
> We have developed a generic concept to annotate TranslationBlocks during
> runtime. The initial idea was to use it for time annotation with data from
> static ana
On 19/01/2016 23:35, Alistair Francis wrote:
> From: Peter Crosthwaite
>
> An API similar to the existing qdev_get_gpio_in() except gets outputs.
> Useful for:
>
> 1: Implementing lightweight devices that don't want to keep pointers
> to their own GPIOs. They can get their GPIO pointers at runtime
On 08/01/2016 11:40, Peter Maydell wrote:
> On 8 January 2016 at 00:39, Alistair Francis
> wrote:
>> On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis
>> wrote:
>>> On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell
>>> wrote:
On 15 December 2015 at 20:52, Peter Crosthwaite
wrote:
>
On 24/11/2015 04:42, Alistair Francis wrote:
> On Mon, Nov 23, 2015 at 6:53 PM, KONRAD Frederic
> wrote:
>>
>> Le 20/11/2015 13:21, Alistair Francis a écrit :
>>> On Fri, Oct 16, 2015 at 7:11 PM, wrote:
From: KONRAD Frederic
This adds the DP and the DPDMA to the Zynq MP platform.
- /dev/null
>> +++ b/hw/display/xlnx_dp.c
>> @@ -0,0 +1,1370 @@
>> +/*
>> + * xlnx_dp.c
>> + *
>> + * Copyright (C) 2015 : GreenSocs Ltd
>> + * http://www.greensocs.com/ , email: i...@greensocs.com
>> + *
>> + * Developed by :
>> + *
Hi Alex,
We decided in Seattle to make this flag per tb (eg move it to the tb
struct).
On 24/02/2016 18:30, Alex Bennée wrote:
> Hi,
>
> So I've been working on reducing MTTCG tb_lock contention and currently
> have a tb_lock around the following code (in my cpu_exec):
>
> /* Note: we do it
On 25/06/2015 01:55, Alexander Spyridakis wrote:
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 process
On 22/06/2015 12:54, Alexander Spyridakis wrote:
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
On 26/06/2015 16:53, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7f0aae9..d1e482a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2664,11 +2664,6 @@ sub process {
On 26/06/2015 16:56, Jan Kiszka wrote:
On 2015-06-26 16:47, fred.kon...@greensocs.com wrote:
From: Jan Kiszka
This finally allows TCG to benefit from the iothread introduction: Drop
the global mutex while running pure TCG CPU code. Reacquire the lock
when entering MMIO or PIO emulation, or whe
On 26/06/2015 16:55, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
From: Guillaume Delbergue
WARNING: spin lock is currently not implemented on WIN32
The Windows KSPIN_LOCK is a kernel data structure. You can implement a
simple, portable test-and-test-and-set sp
On 26/06/2015 16:56, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 971b6db..47345aa 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -11162,6 +11162,8 @@ static inline void
gen
On 26/06/2015 17:02, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This removes tcg_halt_cond global variable.
We need one QemuCond per virtual cpu for multithread TCG.
Signed-off-by: KONRAD Frederic
---
cpus.c | 18 +++---
1
On 26/06/2015 17:15, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
+CPU_FOREACH(cpu) {
+if (qemu_cpu_is_self(cpu)) {
+/* async_run_on_cpu handle this case but this just avoid a malloc
+ * here.
+ */
+tlb_fl
On 26/06/2015 17:35, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
diff --git a/cpu-exec.c b/cpu-exec.c
index de256d6..d6442cd 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
Nice solution. However I still have a few questions that need
clarification.
@@ -382,6 +382,11
On 26/06/2015 17:42, Jan Kiszka wrote:
On 2015-06-26 17:36, Frederic Konrad wrote:
On 26/06/2015 16:56, Jan Kiszka wrote:
On 2015-06-26 16:47, fred.kon...@greensocs.com wrote:
From: Jan Kiszka
This finally allows TCG to benefit from the iothread introduction: Drop
the global mutex while
On 26/06/2015 18:08, Peter Maydell wrote:
On 26 June 2015 at 17:01, Paolo Bonzini wrote:
On 26/06/2015 17:54, Frederic Konrad wrote:
So what happen is:
An arm instruction want to clear tlb of all VCPUs eg: IS version of
TLBIALL.
The VCPU which execute the TLBIALL_IS can't flush tlb of
On 26/06/2015 18:31, Paolo Bonzini wrote:
On 26/06/2015 18:30, Frederic Konrad wrote:
Yes this is not the case as I implemented it.
The rest of the TB will be executed before the tlb_flush work really
happen. The old version did this, was slow and was a mess (if two
VCPUs want to tlb_flush at
On 26/06/2015 18:23, Paolo Bonzini wrote:
On 26/06/2015 18:09, Frederic Konrad wrote:
+void async_run_safe_work_on_cpu(CPUState *cpu, void (*func)(void
*data),
+void *data)
+{
Do you need a mutex to protect this data structure? I would use one
even if not
On 26/06/2015 18:21, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
@@ -1147,7 +1147,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
tb = tb_alloc(pc);
if (!tb) {
/* flush must be done */
-tb_flush(env);
+tb_flush_safe(env);
S
On 26/06/2015 18:20, Paolo Bonzini wrote:
On 26/06/2015 16:47, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
Instead of doing the jump cache invalidation directly in tb_invalidate delay it
after the exit so we don't have an other CPU trying to execute the code being
invalidated.
Sig
Hi,
This is nice.
You should use the checkpatch (script/checkpatch) to check the coding
style of
your patch.
The first is corrupted and there are some coding style issues.
And as Peter suggest use --cover-letter and git send email to send the
emails.
Fred
On 30/06/2015 07:00, Serge Vakulen
On 24/06/2015 08:35, Peter Crosthwaite wrote:
On Mon, Jun 15, 2015 at 8:15 AM, wrote:
From: KONRAD Frederic
This does a write to every slaves when the I2C bus get a write to address 0.
Signed-off-by: KONRAD Frederic
---
hw/i2c/core.c | 46 +-
sing space)
+ * http://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ * Developed by :
+ * Frederic Konrad
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundati
://www.greensocs.com/ , email: i...@greensocs.com
+ *
+ * Developed by :
+ * Frederic Konrad
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2
Hi,
On 30/05/2013 16:47, Cole Robinson wrote:
'default_backend' isn't always set, but 'rng' is, so use that.
$ ./x86_64-softmmu/qemu-system-x86_64 -object
rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0
Segmentation fault (core dumped)
Regressed with virtio refactoring
On 04/06/2013 19:35, Andreas Färber wrote:
Hi,
Am 04.06.2013 18:22, schrieb Jesse Larrew:
Virtio devices are initialized prior to plugging them into a bus. However,
other initializations (such as host_features) don't occur until after the
device is plugged into the bus. If a device needs to mod
On 04/06/2013 22:02, Jesse Larrew wrote:
On 06/04/2013 12:35 PM, Andreas Färber wrote:
Hi,
Hi Andreas!
Thanks for the review. :)
Am 04.06.2013 18:22, schrieb Jesse Larrew:
Virtio devices are initialized prior to plugging them into a bus. However,
other initializations (such as host_feature
On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug yet.
However we still want to hot plug disks.
As a workaround, we could add multiple SCSI host devices (virtio-scsi-pci,
spapr-vscsi) without any disk attached and later (u
On 06/06/2013 15:59, Alexey Kardashevskiy wrote:
On 06.06.2013 22:44, Frederic Konrad wrote:
On 06/06/2013 12:13, Alexey Kardashevskiy wrote:
Hi!
For the pseries platform (server PPC64) we do not support PCI hotplug
yet.
However we still want to hot plug disks.
As a workaround, we could add
On 10/06/2013 13:58, Andreas Färber wrote:
Am 10.06.2013 11:53, schrieb fred.kon...@greensocs.com:
From: KONRAD Frederic
This fix a bug with scsi hotplug on virtio-scsi-pci:
As virtio-scsi-pci doesn't have any scsi bus, we need to forward scsi-hot-add
to the virtio-scsi-device plugged on the
1 - 100 of 270 matches
Mail list logo
