s an emulation thread which
controls multiple VCPU threads...
... then I'm stuck. Somebody can enlighten me? The in-code comments
don't help me anymore, and I'm a little thick following the code
logic.
Thanks!
Alex Barcelo
nasty things. I should migrate,
definitely gonna do it.
Original thread:
http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03638.html
I know that I should repatch it for the new head... but I was waiting
to see if there are things to change before proceeding.
Thanks,
On Sat, Oct 20, 2012 at
, Alex Barcelo wrote:
> ping
>
>
>
>
> On Sat, Oct 20, 2012 at 4:15 PM, Alex Barcelo wrote:
>
>> qemu-user needs SIGSEGV (at least) for some internal use. If the guest
>> application masks it and does unsafe sigprocmask, then the application
>> crashes. Pr
ping
On Sat, Oct 20, 2012 at 4:15 PM, Alex Barcelo wrote:
> qemu-user needs SIGSEGV (at least) for some internal use. If the guest
> application masks it and does unsafe sigprocmask, then the application
> crashes. Problems happen in applications with self-modifying code (who
>
clean and consistent.
The wrapper can be improved to add more features for better signal
managing, but this seems enough for "simple" self-modifying code.
Signed-off-by: Alex Barcelo
---
linux-user/signal.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
di
guest-initiated sigprocmask, but
is not called from internal qemu sigprocmask calls.
Signed-off-by: Alex Barcelo
---
linux-user/qemu.h|1 +
linux-user/signal.c | 10 ++
linux-user/syscall.c | 14 +++---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a
// This self-modifying code will break because of the sigsegv signal block
testfun[ 1]=0x20;
printf ( "0x%02X\n",
((unsigned int (*)())testfun)() );
}
On an i386 native host:
0x0D
0x20
On a non-patched qemu-i386:
0x0D
Segmentation fault
Alex Barce
On Wed, Oct 17, 2012 at 5:01 PM, Peter Maydell wrote:
> On 17 October 2012 15:18, Alex Barcelo wrote:
>> Create a wrapper for signal mask changes initiated by the guest;
>> this will give us a place to put code which prevents the guest
>> from changing the handling of signal
list). I corrected it but now you may have received twice. Next
time I will double check my git output :(
On Wed, Oct 10, 2012 at 5:37 PM, Peter Maydell wrote:
> On 8 October 2012 19:42, Alex Barcelo wrote:
>> okay, now I see that this lacks a lot of "presentation".
>
>
clean and consistent.
The wrapper can be improved to add more features for better signal
managing, but this seems enough for "simple" self-modifying code.
Signed-off-by: Alex Barcelo
---
linux-user/signal.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
di
k
testfun[ 1]=0x20;
printf ( "0x%02X\n",
((unsigned int (*)())testfun)() );
}
On an i386 native host:
0x0D
0x20
On a non-patched qemu-i386:
0x0D
Segmentation fault
Alex Barcelo (2):
signal: added a wrapper for sigprocmask function
signal: sigsegv protectio
qemu sigprocmask calls.
Signed-off-by: Alex Barcelo
---
linux-user/qemu.h|1 +
linux-user/signal.c | 10 ++
linux-user/syscall.c | 14 +++---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index fc4cc00..e2dd6a6
Sat, Sep 29, 2012 at 6:11 PM, Alex Barcelo wrote:
> The first patch creates a sigprocmask wrapper on signal.c for its use in
> syscall.c
>
> The second patch changes the wrapper to protect sigsegv bit on the signal
> mask.
>
> Alex Barcelo (2):
> signal: added a wrapper
the
> code.
>
> Reported-by: Alex Barcelo
> Signed-off-by: Alexander Graf
> ---
> linux-user/syscall.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 8cd56f2..7992b1b 100644
>
This:
struct vfio_iommu_type1_dma_map map = {
.argsz = sizeof(map),
.flags = VFIO_DMA_MAP_FLAG_READ,
.vaddr = (__u64)vaddr,
.iova = iova,
.size = size,
};
(around line 771)
breaks in my environment. I am in a crosschain environment on a i386
buildi
ok, thank you very much. Now I understand the problem... and I see the
correct way of mending it.
Your patch works for me.
>On Mon, Oct 1, 2012 at 1:52 PM, Alexander Graf wrote:
>
> On 30.09.2012, at 20:50, Alex Barcelo wrote:
>
>> This error may be a PPC specific problem
This error may be a PPC specific problem, but I don't have another
environment where I can test it (i386 doesn't seem to use pwrite64),
so I ask for a bit of help/check.
I am in a 32bit linux testing the qemu-ppc.
My test program:
// ---
#include
#include
#include
A transparent wrapper for sigprocmask function.
---
linux-user/qemu.h|1 +
linux-user/signal.c |8
linux-user/syscall.c | 20 ++--
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index fc4cc00..e2dd6a6
The sigsegv protection is done by forcing the catch (needed in qemu-user)
and then taking it off from the return mask (well, adding it in fact)
---
linux-user/signal.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index
The first patch creates a sigprocmask wrapper on signal.c for its use in
syscall.c
The second patch changes the wrapper to protect sigsegv bit on the signal mask.
Alex Barcelo (2):
signal: added a wrapper for sigprocmask function
signal: sigsegv protection on do_sigprocmask
linux-user
>> +
>> +/*
>> + * Use SETSIGNAL and GETSIGNAL macros for SIGSEGV protection.
>> + *
>> + * This should protect SIGSEGV unconscious manipulations from guest apps
>> + * (but we still do not let the emulated software play the signal game)
>> + */
>> +#define SETSIGNAL(set) sigdelset( (set), SIGSEGV)
just finished a git-bisect and I found this... and now I do not fully
understand why I have the problem.
To replicate the error (in a i386 machine, at least):
$ make clean && ./configure --enable-debug && make -j && make install
[Note: I tried both ppc and i386 targets, so doesn't seem machine-dep
issues (I have been playing
around with qemu clock options, but still). But "It Works (TM)".
On Mon, Sep 24, 2012 at 1:23 PM, Alex Barcelo wrote:
>
> There are some situations where the guest application changes the SIGSEGV and
> messes with qemu-user way of handling self-mod
ete signal
protection and achieve bulletproof signal management for every test case,
instead it is a small easy-to-understand patch that resolves the most common
problem.
Signed-off-by: Alex Barcelo
---
linux-user/syscall.c | 18 ++
1 files changed, 18 insertions(+), 0
Thanks a lot! Ok, now it seems a bit clearer :)
On Tue, Sep 18, 2012 at 10:19 AM, Paolo Bonzini wrote:
> Il 18/09/2012 08:27, Alex Barcelo ha scritto:
>>
>> I saw some things[1] about multiple vcpu, smp and things like that. It
>> seemed to me that --enable-io-thread ena
Sorry for being so confused, I am sure that there is some manual which
I haven't read, but I am not able to find it :-\
I saw some things[1] about multiple vcpu, smp and things like that. It
seemed to me that --enable-io-thread enables it. But, it only works
for KVM, doesn't it? I assume that ther
some pointers? What to check? Do I start a new
thread with more detailed information and compilation output? Do I try
to isolate the problem? Is this a easy thing to fix that I have
overlooked?
Thanks,
Alex Barcelo
On Thu, Jun 7, 2012 at 9:39 AM, Paolo Bonzini wrote:
> Signed-off-by: P
Thu, Jan 26, 2012 at 7:32 PM, Alex Barcelo wrote:
> I was trying to add signalfd support on qemu-ppc (specifically, I'm
> doing a configure with "--enable-debug-tcg --enable-debug
> --disable-strip --disable-kvm --disable-bsd-user --disable-darwin-user
> --enable-profiler -
On Thu, May 24, 2012 at 1:04 AM, Peter Maydell wrote:
> On 23 May 2012 23:38, Alex Barcelo wrote:
>> This *always* goes wrong without calling the signal handler
>
> I haven't looked too closely, but I suspect we're just not
> paying any attention to whether memor
>> Running it in a i386 machine works and gives an output of "0x0d\n0x20".
>> Running it in a qemu-i386 segfaults. Because the self-modifying code
>> raises a SIGSEGV in the qemu (I understand that it is the method used by
>> qemu to handle self-modifying code). But the sigprocmask disables the
>>
I'm working in a "big" (=complex, strange) project[1] and come across a bug
in signal management. I have been able to narrow it down to this program:
#include
#include
#include
#include
#include
#include
unsigned char *testfun;
int main ( void )
{
unsigned int ra;
testfun=memalign(
at 12:47, Alexander Graf wrote:
>
> On 15.03.2012, at 12:41, Stefan Hajnoczi wrote:
>
>> On Thu, Mar 15, 2012 at 8:52 AM, Alex Barcelo wrote:
>>> I tried to send a trivial patch and a v2, but I did it horribly wrong
>>> and seems that have not yet been updated.
Each architecture does the same comparation, but it is hard
(at least was hard for me) to see, because of the fancy way
of doing a simple 0 comparation.
This patch simply tries to assure signal.c code coherence.
Signed-off-by: Alex Barcelo
---
linux-user/signal.c | 44
ld be coherent and
correct across archs.
Signed-off-by: Alex Barcelo
---
linux-user/signal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index d1a2671..d159ada 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -4122,7 +4
ndition.
I sent two "[TRIVIAL]" to the lists that are irrelevant with this
patch. They are:
"sas_ss_flags bug for powerpc"
(v2) "Bad zero comparison for sas_ss_flags on powerpc"
Alex Barcelo (2):
linux-user: Homogeneity on sas_ss_flags checks (signal)
linux-user: B
On Wed, Mar 7, 2012 at 23:17, Peter Maydell wrote:
> On 7 March 2012 22:01, Alex Barcelo wrote:
>> Is this patch okay? The first version had some comments, and now the
>> v2 has been a bit too silent, not sure if that's a good sign or a bad
>> sign.
>
> Did y
Is this patch okay? The first version had some comments, and now the
v2 has been a bit too silent, not sure if that's a good sign or a bad
sign.
Thanks & sorry!
On Tue, Feb 28, 2012 at 12:25, Alex Barcelo wrote:
> This series of patches implements coroutines method with
> sigal
Configure tries, as a default, ucontext functions for the
coroutines. But now the user can force another backend by
--with-coroutine=BACKEND option
v2: Using --with-coroutine=BACKEND instead of enable
disable individual configure options
Signed-off-by: Alex Barcelo
---
configure | 37
It's possible to use sigaltstack backend with --with-coroutine=sigaltstack
v2: changed from enable/disable configure flags
Signed-off-by: Alex Barcelo
---
Makefile.objs |4
configure |6 +-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Makefile.o
).
Signed-off-by: Alex Barcelo
---
coroutine-sigaltstack.c | 334 +++
1 files changed, 334 insertions(+), 0 deletions(-)
create mode 100644 coroutine-sigaltstack.c
diff --git a/coroutine-sigaltstack.c b/coroutine-sigaltstack.c
new file mode 100644
index
(file pth_mctx.c, variant 2).
This v2 has some corrections and improved patches, but it's
essentially the same. At the moment, the default backend is
ucontext (the former default method for coroutines).
Alex Barcelo (3):
coroutine: adding sigaltstack method (.c source)
coroutine: a
).
Signed-off-by: Alex Barcelo
---
test-coroutine.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/test-coroutine.c b/test-coroutine.c
index bf9f3e9..7425dad 100644
--- a/test-coroutine.c
+++ b/test-coroutine.c
@@ -177,6 +177,32 @@ static void
On Wed, Feb 15, 2012 at 09:35, Alexander Graf wrote:
> On 15.02.2012, at 07:55, Alex Barcelo wrote:
>> ping? is this ok? Or it is not trivial at all, and better do a normal patch?
>> And write it better?
>
> The patch is fine, but it's not trivial. It's a ppc patc
ping? is this ok? Or it is not trivial at all, and better do a normal
patch? And write it better?
I have no inconvenience on doing so, but I didn't want to duplicate patches
in the list.
El 10/02/2012 10:57, "Alex Barcelo" escribió:
> // Test source and desired /real ou
On Tue, Feb 14, 2012 at 13:20, Stefan Hajnoczi wrote:
> On Tue, Feb 14, 2012 at 11:53 AM, Alex Barcelo wrote:
>> On Tue, Feb 14, 2012 at 10:24, Stefan Hajnoczi wrote:
>>> (...)
>>> What happens when a vcpu thread creates a coroutine while another QEMU
>>>
On Tue, Feb 14, 2012 at 13:17, Stefan Hajnoczi wrote:
> On Tue, Feb 14, 2012 at 11:38 AM, Alex Barcelo wrote:
>> On Tue, Feb 14, 2012 at 09:33, Stefan Hajnoczi wrote:
>>> On Mon, Feb 13, 2012 at 04:11:15PM +0100, Alex Barcelo wrote:
>>>> This new implementation...
On Tue, Feb 14, 2012 at 10:24, Stefan Hajnoczi wrote:
> On Mon, Feb 13, 2012 at 03:42:28PM +0100, Alex Barcelo wrote:
>> + if (!setjmp(*((jmp_buf *)&tr_reenter))) {
>> + return;
>> + }
>
> setjmp() followed by return is usually bad. We're relyin
On Tue, Feb 14, 2012 at 09:33, Stefan Hajnoczi wrote:
> On Mon, Feb 13, 2012 at 04:11:15PM +0100, Alex Barcelo wrote:
>> This new implementation... well, it seems to work (I have done an
>> ubuntu installation with a cdrom and a qcow drive, which seems to use
>> quite a l
On Mon, Feb 13, 2012 at 16:57, Andreas Färber wrote:
> You should (need to?) use version 2.1 or later above then, too. You can
> then simply move this snippet up and drop the "Same license ..." line.
I wanted to ask this, but it slipped my mind. So it's ok to change the
header to a newer GNU vers
On Mon, Feb 13, 2012 at 15:49, Daniel P. Berrange wrote:
> Since the 3 different coroutine impls are mutually exclusive
> choices, perhaps it'd be preferable to just have a single
> configure argument like
>
> --with-couroutines=[ucontext|sigaltstack|gthread]
>
> Thus avoiding the non-sensical s
On Mon, Feb 13, 2012 at 15:51, Peter Maydell wrote:
> On 13 February 2012 14:42, Alex Barcelo wrote:
>> This series of patches implements coroutines method with
>> sigaltstack.
>>
>> The flow of creation and management of the coroutines is
>> quite similar to the
It's possible to enable/disable sigaltstack, but it always has
less priority than ucontext method (to force sigaltstack,
ucontext has to be disabled).
Signed-off-by: Alex Barcelo
---
Makefile.objs |4
configure | 39 +++
2 files change
Configure tries, as a default, ucontext functions for the
coroutines. But now the user can force its use or disable
it at all (enable and disable flags)
Signed-off-by: Alex Barcelo
---
configure | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a
This file is based in both coroutine-ucontext.c and
pth_mctx.c (from the GNU Portable Threads library).
The mechanism used to change stacks is the sigaltstack
function (variant 2 of the pth library).
Signed-off-by: Alex Barcelo
---
coroutine-sigaltstack.c | 337
(file pth_mctx.c, variant 2).
It's my first patch, I'm sure that there are things that I
have done wrong. Please, be kind :)
Thanks for your time
Alex Barcelo (3):
coroutine: adding sigaltstack method (.c source)
coroutine: adding control flags (enable/disable) for ucontext
c
I have sent a v2 of this patch (renaming it, with a description and a
test case). If it's not trivial and I have to send it in another way,
I will do so.
Sorry for the inconvenience, as I said I'm new here and maybe I
misunderstood the "trivial" category.
// Test source and desired /real output:
#include
#include
#include
#include
void handler(int sig)
{
unsigned int a;
// to prevent uninitialized stack, normally a = 0
if ( a>10 ) a = 0;
a = a + 1;
printf ("new value: %d\n" , a );
if (a > 7) _exit(a);
return;
}
int main()
done wrong only for this
architecture, it's more a typo than a bug). It's NOT ppc specific,
it's POSIX standard (sigaltstack) and qemu internal.
I have a test source that I will send in a follow-up (it's longer than
I would have wished, I'm sure that a better test case can be
On Thu, Feb 9, 2012 at 19:43, Andreas Färber wrote:
> Am 09.02.2012 19:30, schrieb Alex Barcelo:
>> Signed-off-by: Alex Barcelo
>
> This patch needs a better description than "bug",
sorry, something like "Incorrect zero comparison in sas_ss_flags"
would have
On Sun, Feb 5, 2012 at 00:00, Peter Maydell wrote:
> On 4 February 2012 14:26, Alex Barcelo wrote:
>> (...)
> This looks like a bug, yes -- the other architectures have the !
> (or equivalent code) in their get_sigframe() implementations so
> probably ppc is just wrong here.
Ye
Signed-off-by: Alex Barcelo
---
linux-user/signal.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 79a39dc..26e0530 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -4115,7 +4115,7 @@ static target_ulong
On Tue, Feb 7, 2012 at 12:18, Stefan Hajnoczi wrote:
> On Sat, Jan 28, 2012 at 9:31 AM, Alex Barcelo wrote:
>> On Fri, Jan 27, 2012 at 15:39, Paolo Bonzini wrote:
>>>> I have a patch that uses sigsetjmp and siglongjmp instead of
>>>> makecontext and getcontext
I am barely able to understand this inline function:
static inline int sas_ss_flags(unsigned long sp)
{
return (target_sigaltstack_used.ss_size == 0 ? SS_DISABLE
: on_sig_stack(sp) ? SS_ONSTACK : 0);
}
(signal.c @97)
... and it seems wrong to me when used in the following function
On Fri, Jan 27, 2012 at 15:39, Paolo Bonzini wrote:
>> I have a patch that uses sigsetjmp and siglongjmp instead of
>> makecontext and getcontext (and all the ucontext stuff), and it
>> *seems* to work... but I'm not sure if it works "by accident" (not
>> sure what I'm doing to the stack, not sure
I have read that one of the reasons for using makecontext is that it
saves the signal state. But there also exist functions like
"sigsetjmp" and "siglongjmp" which can be used to jump around the
coroutines while preserving signal masks.
I have a patch that uses sigsetjmp and siglongjmp instead of
I was trying to add signalfd support on qemu-ppc (specifically, I'm
doing a configure with "--enable-debug-tcg --enable-debug
--disable-strip --disable-kvm --disable-bsd-user --disable-darwin-user
--enable-profiler --target-list=ppc-linux-user --disable-curl
--enable-nptl").
At first I thought tha
66 matches
Mail list logo
