[Qemu-devel] [PATCH 0/5] linux-user: Support signal passing for targets having more signals than host

Aleksandar Markovic posted 5 patches 4 years, 10 months ago
Test FreeBSD passed
Test docker-clang@ubuntu failed
Test s390x passed
Test docker-mingw@fedora passed
Test checkpatch passed
Test asan passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/1558550785-20098-1-git-send-email-aleksandar.markovic@rt-rk.com
Maintainers: Riku Voipio <riku.voipio@iki.fi>, Laurent Vivier <laurent@vivier.eu>
linux-user/mips/signal.c   |  16 ++++
linux-user/qemu.h          |  11 +++
linux-user/signal-common.h |   5 ++
linux-user/signal.c        | 217 ++++++++++++++++++++++++++++++++++++++++++++-
linux-user/syscall.c       | 178 +++++++++++++++++++++++++++++++++++++
linux-user/syscall_defs.h  |  32 +++++++
6 files changed, 457 insertions(+), 2 deletions(-)
[Qemu-devel] [PATCH 0/5] linux-user: Support signal passing for targets having more signals than host
Posted by Aleksandar Markovic 4 years, 10 months ago
From: Aleksandar Markovic <amarkovic@wavecomp.com>

Most of the targets (including Intel) define 64 signals. This
creates difficulties for targets that define, for example, 128
signals. This series adds support for signal passing even if
the host defines less signals than the target.

Miloš Stojanović (5):
  linux-user: Fix sigismember() check
  linux-user: Add support for tracking the target signal mask
  linux-user: Add functionality for tracking target signal mask
  linux-user: Add support for multiplexing larger target signals
  linux-user: Add support for multiplexing signals in more syscalls

 linux-user/mips/signal.c   |  16 ++++
 linux-user/qemu.h          |  11 +++
 linux-user/signal-common.h |   5 ++
 linux-user/signal.c        | 217 ++++++++++++++++++++++++++++++++++++++++++++-
 linux-user/syscall.c       | 178 +++++++++++++++++++++++++++++++++++++
 linux-user/syscall_defs.h  |  32 +++++++
 6 files changed, 457 insertions(+), 2 deletions(-)

-- 
2.7.4


Re: [Qemu-devel] [PATCH 0/5] linux-user: Support signal passing for targets having more signals than host
Posted by Peter Maydell 4 years, 10 months ago
On Wed, 22 May 2019 at 19:57, Aleksandar Markovic
<aleksandar.markovic@rt-rk.com> wrote:
>
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
>
> Most of the targets (including Intel) define 64 signals. This
> creates difficulties for targets that define, for example, 128
> signals. This series adds support for signal passing even if
> the host defines less signals than the target.

Could you elaborate a bit on how much functionality
is provided for signal numbers which the target has
but the host does not? For instance, it seems likely
that attempts by the guest to kill(other_pid, sig) will
fail if sig is not in the supported-by-the-target range.
But is it possible for the guest process to deliver
one of these signals to itself ?

This patchset is interesting because in fact pretty much
every target supports more signals than our host code
can provide, because the host libc steals several
signals for its own purposes and QEMU can't use them.
Being able to multiplex several guest signals onto
one host signal might let us run some guest binaries
we currently can't handle correctly.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 0/5] linux-user: Support signal passing for targets having more signals than host
Posted by Aleksandar Markovic 4 years, 10 months ago
On May 23, 2019 3:46 PM, "Peter Maydell" <peter.maydell@linaro.org> wrote:
>
> On Wed, 22 May 2019 at 19:57, Aleksandar Markovic
> <aleksandar.markovic@rt-rk.com> wrote:
> >
> > From: Aleksandar Markovic <amarkovic@wavecomp.com>
> >
> > Most of the targets (including Intel) define 64 signals. This
> > creates difficulties for targets that define, for example, 128
> > signals. This series adds support for signal passing even if
> > the host defines less signals than the target.
>
> Could you elaborate a bit on how much functionality
> is provided for signal numbers which the target has
> but the host does not? For instance, it seems likely
> that attempts by the guest to kill(other_pid, sig) will
> fail if sig is not in the supported-by-the-target range.
> But is it possible for the guest process to deliver
> one of these signals to itself ?
>
> This patchset is interesting because in fact pretty much
> every target supports more signals than our host code
> can provide, because the host libc steals several
> signals for its own purposes and QEMU can't use them.
> Being able to multiplex several guest signals onto
> one host signal might let us run some guest binaries
> we currently can't handle correctly.
>

Hello, Peter.

I would ask the author, Milos Stojanovic, to provide us with details you
asked for.

I am here just the integrator and the submitter, and even though I could
perhaps answer your questions accurately, I would prefer Milos as the main
person to talk to.

I would like to add that this series is already in exploation here in Wave,
for some internal projects involving QEMU. People are happy with it, it
solved some long-standing problems, and there is no known open issue
related to this code.

The solution has its own limitations, as is spelled out in commit messages,
just to keep your expectations realistic, but overall I find it incredibly
useful, and very good, given the complex problem it tackles.

I would like now to pass the “floor” to Milos.

Yours,
Aleksandar

> thanks
> -- PMM
>
Re: [Qemu-devel]?==?utf-8?q? ?==?utf-8?q? [PATCH 0/5]?==?utf-8?q? linux-user: Support signal passing for targets having more signals than host
Posted by Milos Stojanovic 4 years, 10 months ago
Hello, Peter.
For this implemenation rt_sigqueueinfo()/rt_tgsigqueueinfo() were used to multiplex signals that are out of the host range. This enabled the use of a wider signal range with rt_sigqueueinfo(), rt_tgsigqueueinfo(), as well as kill() (for pid > 0) and tgkill(). A process can now use these system calls to send a range of signals which weren't supporeted before to itself or others threads or processes.

The tkill() system call and kill() with the argument pid <= 0 couldn't be implemented simply using this method because it requires acquiring information about, and sending simultaneous signals to multiple threads or processes and these functionalities are out of the scope of rt_sigqueueinfo()/rt_tgsigqueueinfo().

This patch set was primarily focused on expanding the range of real-time signals and making them usable but some limitations still remain. For example, the priority of those real-time signals, as defined by POSIX, doesn't depend on the actual signal number but on the host signal nuber which is used for multiplexing.
As it now is, the functionaly is only enabled for signals that are higher-numbered then the host signals but I don't see a conceptual problem in expanding and testing the implenentation to include other signals (e.g. the signals that NPTL uses).

Regards,
Miloš