qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Richard Henderson <richard.henderson@linaro.org>, qemu-devel@nongnu.org
Cc: cohuck@redhat.com, qemu-s390x@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-4.0 2/2] target/s390x: Implement STCK et al for CONFIG_USER_ONLY
Date: Mon, 3 Dec 2018 11:21:11 +0100	[thread overview]
Message-ID: <cf30fb27-a5a3-6614-1053-351ffc8555c3@redhat.com> (raw)
In-Reply-To: <20181130192216.26987-3-richard.henderson@linaro.org>

On 30.11.18 20:22, Richard Henderson wrote:
> This is a non-privileged instruction that was only implemented
> for system mode.  However, the stck instruction is used by glibc,
> so this was causing SIGILL for programs run under debian stretch.
> 
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  target/s390x/helper.h      |  2 +-
>  target/s390x/misc_helper.c | 13 ++++++++++++-
>  target/s390x/translate.c   |  2 ++
>  target/s390x/insn-data.def | 11 ++++++-----
>  4 files changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/target/s390x/helper.h b/target/s390x/helper.h
> index 018e9dd414..6260b50496 100644
> --- a/target/s390x/helper.h
> +++ b/target/s390x/helper.h
> @@ -121,13 +121,13 @@ DEF_HELPER_4(cu41, i32, env, i32, i32, i32)
>  DEF_HELPER_4(cu42, i32, env, i32, i32, i32)
>  DEF_HELPER_5(msa, i32, env, i32, i32, i32, i32)
>  DEF_HELPER_FLAGS_1(stpt, TCG_CALL_NO_RWG, i64, env)
> +DEF_HELPER_FLAGS_1(stck, TCG_CALL_NO_RWG_SE, i64, env)
>  
>  #ifndef CONFIG_USER_ONLY
>  DEF_HELPER_3(servc, i32, env, i64, i64)
>  DEF_HELPER_4(diag, void, env, i32, i32, i32)
>  DEF_HELPER_3(load_psw, noreturn, env, i64, i64)
>  DEF_HELPER_FLAGS_2(spx, TCG_CALL_NO_RWG, void, env, i64)
> -DEF_HELPER_FLAGS_1(stck, TCG_CALL_NO_RWG_SE, i64, env)
>  DEF_HELPER_FLAGS_2(sck, TCG_CALL_NO_RWG, i32, env, i64)
>  DEF_HELPER_FLAGS_2(sckc, TCG_CALL_NO_RWG, void, env, i64)
>  DEF_HELPER_FLAGS_2(sckpf, TCG_CALL_NO_RWG, void, env, i64)
> diff --git a/target/s390x/misc_helper.c b/target/s390x/misc_helper.c
> index 3f91579570..c2940afecb 100644
> --- a/target/s390x/misc_helper.c
> +++ b/target/s390x/misc_helper.c
> @@ -76,8 +76,19 @@ uint64_t HELPER(stpt)(CPUS390XState *env)
>  #endif
>  }
>  
> -#ifndef CONFIG_USER_ONLY
> +#ifdef CONFIG_USER_ONLY
> +/* Store Clock */
> +uint64_t HELPER(stck)(CPUS390XState *env)
> +{
> +    struct timespec ts;
> +    uint64_t ms;
>  
> +    clock_gettime(CLOCK_REALTIME, &ts);
> +    ms = (ts.tv_nsec / 1000) + (ts.tv_sec * 100000ull);
> +
> +    return TOD_UNIX_EPOCH + ms;

In theory, the TOD can be completely controlled by the operating system
(e.g. set the TOD to X). So for user space, there isn't really any
guarantee about the values returned via stck.

E.g. in the PoP 4-51:

"4. A program using the clock value as a time-of-day
and calendar indication must be consistent with
the programming support under which the pro-
gram is to be executed. [...]"

Of course, in an ideal world, the system TOD value really corresponds to
the reference TOD. So I assume, in theory, we can simply indicate any
monotonic values here. E.g. not using TOD_UNIX_EPOCH and only forwarding
the result from CLOCK_REALTIME converted to appropriate TOD values.

If I am not wrong, under Linux, user space will only use stck for
measurement, and use the vdso for getting the real time.


-- 

Thanks,

David / dhildenb

  parent reply	other threads:[~2018-12-03 10:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 19:22 [Qemu-devel] [PATCH for-4.0 0/2] target/s390x: Implement STCK et al for CONFIG_USER_ONLY Richard Henderson
2018-11-30 19:22 ` [Qemu-devel] [PATCH for-4.0 1/2] target/s390x: Move TOD_UNIX_EPOCH to cpu.h Richard Henderson
2018-12-03  6:07   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-12-03 10:21   ` [Qemu-devel] " David Hildenbrand
2018-11-30 19:22 ` [Qemu-devel] [PATCH for-4.0 2/2] target/s390x: Implement STCK et al for CONFIG_USER_ONLY Richard Henderson
2018-12-03  6:19   ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2018-12-03 13:27     ` Richard Henderson
2018-12-03 14:02       ` Thomas Huth
2018-12-03 14:29         ` Richard Henderson
2018-12-03 14:31           ` Thomas Huth
2018-12-03 14:51         ` David Hildenbrand
2018-12-03 10:21   ` David Hildenbrand [this message]
2018-12-03 13:30     ` [Qemu-devel] " Richard Henderson
2018-12-03 14:48       ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf30fb27-a5a3-6614-1053-351ffc8555c3@redhat.com \
    --to=david@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).