linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Simon Guo <wei.guo.simon@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
	Simon Guo <wei.guo.simon@gmail.com>,
	Rashmica Gupta <rashmicy@gmail.com>,
	linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space
Date: Thu,  7 Jul 2016 21:15:33 +1000 (AEST)	[thread overview]
Message-ID: <3rlZmP39HNz9sXR@ozlabs.org> (raw)
In-Reply-To: <1467877776-5618-1-git-send-email-wei.guo.simon@gmail.com>

On Thu, 2016-07-07 at 07:49:36 UTC, Simon Guo wrote:
> From: Simon Guo <wei.guo.simon@gmail.com>
> 
> These 2 fields track whether user process has used Altivec/VSX
> registers or not. They are used by kernel to setup signal frame
> on user stack correctly regarding vector part.

I still dislike this. It's just exporting internal kernel state, which I know is
the point.

And I'd still like to know why we're the only arch that needs to do this.

I'm not saying I won't merge it, but I'd like to understand it better first.

> CRIU(Checkpoint and Restore In User space) builds signal frame
> for restored process. It will need this export information to
> setup signal frame correctly. And CRIU will need to restore these
> 2 fields for the restored process.

I don't really know how CRIU works, but ..

Does the kernel write a sigframe for the process that's being checkpointed? If
so can't you infer the state of the bits based on what was written?

Alternately, when restoring, can you setup the sigframe with the Altivec/VSX
fields populated, and the kernel will then load them, regardless of whether
they were actually used or not prior to the checkpoint?

cheers

  reply	other threads:[~2016-07-07 11:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-07  7:49 [PATCH v4] powerpc: Export thread_struct.used_vr/used_vsr to user space wei.guo.simon
2016-07-07 11:15 ` Michael Ellerman [this message]
2016-07-07 13:12   ` [v4] " Laurent Dufour
2016-07-07 13:21     ` Benjamin Herrenschmidt
2016-07-07 13:29       ` Benjamin Herrenschmidt
2016-07-08 10:02         ` Michael Ellerman
     [not found]         ` <577f7a45.568f6b0a.bd0eb.4aa8SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-11 17:39           ` Simon Guo
2016-07-15  7:15           ` Simon Guo
2016-07-21 10:57             ` Michael Ellerman
     [not found]             ` <5790aa9c.05296b0a.adf58.5901SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-25  8:52               ` Simon Guo
2016-07-07 13:40       ` Laurent Dufour
2016-07-08  8:26         ` Michael Ellerman
2016-07-08  5:39       ` Simon Guo

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=3rlZmP39HNz9sXR@ozlabs.org \
    --to=mpe@ellerman.id.au \
    --cc=keescook@chromium.org \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=rashmicy@gmail.com \
    --cc=wei.guo.simon@gmail.com \
    /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).