On 13 août 2014 16:27:29 CEST, "Benoît Canet" wrote:
> The Wednesday 13 Aug 2014 à 18:08:47 (+0800), Ming Lei wrote :
> > This test runs dummy function with coroutine by using
> > two enter and one yield since which is a common usage.
> >
> > So we can see the cost introduced by corouting for r
On Thu, Oct 10, 2013 at 11:14:22PM +0100, Gabriel Kerneis wrote:
> We were so excited about our QEMU/CPC GSoC project that we have decided
> to write a 12-page article to share our experience
Our "QEMU/CPC" paper has been accepted for publication at PEPM'14:
http://www.progr
On Sun, Oct 27, 2013 at 04:23:54PM +0100, Charlie Shepherd wrote:
> These patches were the first two from my GSoC series and were reasonably
> straight-forward and well accepted. Gabriel and I are hoping the patches from
> GSoC can be merged before I start my job in December, so I'm starting by
>
On Fri, Oct 11, 2013 at 01:34:02PM +0200, Pierre Tardy wrote:
> This indeed deserve some congrats, and looks interesting. Do you have an
> epub version, so that one can study this confortably in an ebook reader?
HTML: http://gabriel.kerneis.info/research/files/qemu-cpc/
(generated from latex
Hi Pierre,
On Fri, Oct 11, 2013 at 01:34:02PM +0200, Pierre Tardy wrote:
> Do I summarized too much if I say that this is about automatically
> translating thread based code to event driven code?
This is exactly what CPC is about. If you want more details on the
translation itself, you might be
resource for
prospective students looking for an example of past GSoC projects.
Thanks to Google, and everybody involved, for making this great project
possible.
--
Gabriel Kerneis
http://gabriel.kerneis.info/
On Sun, Oct 06, 2013 at 07:47:02AM +0200, Stefan Weil wrote:
> What about removing the comment with the configure parameters
> from config-host.mak?
Sound like a good idea.
> * Easier code - no need to create a configure call from a comment.
Note we still need some escaping for single quotes, bu
On Sun, Oct 06, 2013 at 12:54:08AM +0900, Peter Maydell wrote:
> So this sed script appears to convert literal newlines in the input
> Is that what's intended?
Yes.
> It doesn't seem very useful because if you cut-n-paste (or pipe)
> 'hello\nworld' into a shell you get an actual backslash-n, not
Escape single quotes and newlines when writing configure arguments
to config-host.mak. This is necessary to allow correct regeneration
by re-executing configure in a shell when config-host.mak becomes
out-of-date.
Signed-off-by: Gabriel Kerneis
---
configure | 6 +-
1 file changed, 5
On Tue, Oct 01, 2013 at 07:51:24AM +0200, Stefan Weil wrote:
> $ wine i386-softmmu/qemu-system-i386 -L pc-bios -cdrom /var/tmp/mini.iso
> -sdl # or -vnc :1
>
> => Assertion in qemu-coroutine-lock.c:99.
Could you please provide the backtrace for this? I am curious which of the uses
of qemu_co_que
reasonable amount of
time.
Signed-off-by: Gabriel Kerneis
---
tests/test-coroutine.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/test-coroutine.c b/tests/test-coroutine.c
index f4f90ac..668d88f 100644
--- a/tests/test-coroutine.c
+++ b/tests/test-coroutine.c
Current coroutine performance benchmarks test only coroutine creation,
either directly or in a nested way. This patch adds a benchmark to
evaluate the performance of qemu_coroutine_yield.
Signed-off-by: Gabriel Kerneis
---
tests/test-coroutine.c | 33 +
1 file
On Fri, Sep 13, 2013 at 08:38:58AM +0100, Gabriel Kerneis wrote:
> But I'm nonetheless hitting a bug in CIL simplifications and I have a hard
> time tracking it down.
Fixed!
https://github.com/kerneis/cil/commit/640994197bed274c373d585decbe9ebe2073f014
Thanks to everybody
On Fri, Sep 13, 2013 at 08:38:58AM +0100, Gabriel Kerneis wrote:
> So CIL introduces a bug in TCG which prevents >= 3.2 kernels from booting with
> the above error message, but I have absolutely no clue which files of QEMU's
> code
> might be involved.
Some more bisections l
Dear all,
I am using CIL [1] to compile QEMU. CIL is a wrapper around gcc which can be
used to analyse C code. As explained recently on this list, the ultimate goal is
to check coroutine_fn annotations statically [2]. When CIL compiles C code, it
performs a number of simplifications, which are sup
On Wed, Sep 11, 2013 at 04:01:37PM +0100, Gabriel Kerneis wrote:
> On Wed, Sep 11, 2013 at 04:53:35PM +0200, Paolo Bonzini wrote:
> > Oh, then it's this line in configure that has to be changed to do proper
> > quoting.
> >
> > printf "# Configured with:&
On Wed, Sep 11, 2013 at 04:16:28PM +0100, Gabriel Kerneis wrote:
> > Yeah, what I'm missing now is why your patch works.
>
> That is indeed very mysterious :-)
Okay, the answer is simple enough: it doesn't fix the issue at all.
Long story short, I had a sed script
On Wed, Sep 11, 2013 at 05:24:55PM +0200, Kevin Wolf wrote:
> In config-host.make we do get:
>
> CONFIG_COROUTINE_POOL=0
>
> But when config-host.h is generated from it, I assume it's only checked
> if the variable is defined, so we end up with:
>
> #define CONFIG_COROUTINE_POOL 1
Did y
On Wed, Sep 11, 2013 at 04:53:35PM +0200, Paolo Bonzini wrote:
> Oh, then it's this line in configure that has to be changed to do proper
> quoting.
>
> printf "# Configured with:" >> $config_host_mak
> printf " '%s'" "$0" "$@" >> $config_host_mak
No, this line has absolutely nothing to do with i
On Wed, Sep 11, 2013 at 05:06:41PM +0200, Paolo Bonzini wrote:
> > The line that has to be fixed is
> > really the line starting with "extra_cflags=" in config-host.mak (well,
> > at least in my experience - my patch does not touch the first line, at
> > it still solves the issue).
>
> Yeah, what
g).
>
> Reported-by: Gabriel Kerneis
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Gabriel Kerneis
--
Gabriel
On Wed, Sep 11, 2013 at 04:01:50PM +0200, Paolo Bonzini wrote:
> > ./configure --extra-cflags="-Dcoroutine_fn='__attribute__((coroutine_fn))'"
>
> Where does the shell read config-host.mak? Make does not need the quotes.
I might have been confused about the shell vs. make interpreting the
string
="-Dcoroutine_fn='__attribute__((coroutine_fn))'"
A more robust approach would be to escape every variable properly, but
there is no portable equivalent to bash's "printf %q" solution. The
current patch, while not bullet-proof, works well in the common case.
Signed-off-
On Fri, Sep 06, 2013 at 04:36:47PM +0100, Charlie Shepherd wrote:
> However, I'm not sure it makes sense to use blocking_fn until the
> convert-block series (which currently needs a respin after Stefan's
> review) is fully upstreamed. Maybe this patch makes most sense at
> the start of that series?
On Fri, Sep 06, 2013 at 03:30:38PM +0100, Gabriel Kerneis wrote:
> More precisely, here is what CoroCheck does for each file of QEMU:
> - produce a .dot file that can be processed with graphviz to produce a
> pdf of the annotated call graph (with wrong annotations showing up in
>
in coroutine context.
Signed-off-by: Gabriel Kerneis
---
include/block/coroutine.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/block/coroutine.h b/include/block/coroutine.h
index 4232569..a92d14f 100644
--- a/include/block/coroutine.h
+++ b/include/block
ve/html/qemu-devel/2013-08/msg00529.html
[3] https://github.com/kerneis/corocheck
[4] https://github.com/kerneis/corocheck#qemu
[5] http://kerneis.github.io/cil/
Gabriel Kerneis (1):
Introduce blocking_fn annotation
include/block/coroutine.h | 23 +++
1 file changed, 23 insertions(+)
--
1.7.10.4
On Thu, Aug 08, 2013 at 10:10:18AM +0100, Charlie Shepherd wrote:
> >Note that qemu_coroutine_self() in principle really needs to be annotated
> >coroutine_fn since it accesses (and returns) its execution context. The fact
> >that it is implemented with thread-local variables in Qemu is an
> >impl
On Wed, Aug 07, 2013 at 09:30:25PM +0200, Stefan Hajnoczi wrote:
> I have mixed feelings about removing coroutine_fn annotations from a
> function when it does not yield or call other coroutine_fn functions.
>
> These functions were probably written as part of a coroutine code path.
> The coroutin
On Thu, Aug 08, 2013 at 02:29:39AM +0100, Charlie Shepherd wrote:
> On 07/08/2013 23:13, Gabriel Kerneis wrote:
> >On Wed, Aug 07, 2013 at 09:18:05PM +0200, Stefan Hajnoczi wrote:
> >>I guess the practical problem is that CPC will get
> >>upset that it'
On Wed, Aug 07, 2013 at 09:18:05PM +0200, Stefan Hajnoczi wrote:
> I guess the practical problem is that CPC will get
> upset that it's being called by the coroutine implementation from
> non-coroutine contexts.
But is it really the case? If Charlie added an annotation, it probably means
that in p
On Mon, Aug 05, 2013 at 08:44:02PM +0200, Charlie Shepherd wrote:
> This patch series is a follow up to a previous RFC about converting functions
> that dynamically yield execution depending on whether they are in executing in
> a coroutine context or not to be explicitly statically annotated.
Ano
On Mon, Aug 05, 2013 at 08:44:07PM +0200, Charlie Shepherd wrote:
> This patch updates the callers of block layer functions converted to explicit
> coroutine_fn annotation in the previous patch.
It looks like this patch is made of three parts:
- updating the annotations, following the rule "caller
On Mon, Aug 05, 2013 at 08:33:10PM +0100, Charlie Shepherd wrote:
> Yes that does merit some explanation.
Thanks for the details.
> qemu_co_queue_run_restart is a bit different. It is only called from
> coroutine_swap in qemu-coroutine.c, and it enters coroutines that
> were waiting but have now
On Mon, Aug 05, 2013 at 08:44:06PM +0200, Charlie Shepherd wrote:
> This patch follows on from the previous one and converts some block layer
> functions to be
> explicitly annotated with coroutine_fn instead of yielding depending upon
> calling context.
And just like the previous one, it also r
Hi Charlie,
Many thanks for this patch series.
On Mon, Aug 05, 2013 at 08:44:05PM +0200, Charlie Shepherd wrote:
> This patch converts the .bdrv_open, .bdrv_file_open and .bdrv_create members
> of struct BlockDriver
> to be explicitly annotated as coroutine_fn, rather than yielding dynamically
On Tue, Jul 23, 2013 at 03:36:28PM +0200, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2013 at 01:10:35PM +0100, Gabriel Kerneis wrote:
> > On Tue, Jul 23, 2013 at 02:05:15PM +0200, Stefan Hajnoczi wrote:
> > > A built-time check for coroutine_fn would be valuable if we ever
On Tue, Jul 23, 2013 at 02:05:15PM +0200, Stefan Hajnoczi wrote:
> A built-time check for coroutine_fn would be valuable if we ever hope to
> get disciplined with this annotation.
>
> The check can detect when a coroutine_fn is invoked outside coroutine
> context. I wonder if Coccinelle can detec
support __uint128_t.
Signed-off-by: Gabriel Kerneis
---
target-s390x/int_helper.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target-s390x/int_helper.c b/target-s390x/int_helper.c
index af16b21..85e49aa 100644
--- a/target-s390x/int_helper.c
+++ b/target-s390x/int_helper.c
39 matches
Mail list logo
