All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	hjl.tools@gmail.com
Subject: Re: [patch v2 2/4] x86, ptrace: regset extensions to support xstate
Date: Tue,  9 Feb 2010 17:30:31 -0800 (PST)	[thread overview]
Message-ID: <20100210013031.208FB73D8@magilla.sf.frob.com> (raw)
In-Reply-To: Suresh Siddha's message of  Tuesday, 9 February 2010 12:13:11 -0800 <20100209202502.216592031@sbs-t61.sc.intel.com>

> Add the xstate regset support which helps extend the kernel ptrace and the
> core-dump interfaces to support AVX state etc.
> 
> This regset interface is designed to support all the future state that gets
> supported using xsave/xrstor infrastructure.

Looks good modulo cosmetic nits below.

> And hence the xsave memory layout available through this regset
> interface uses SW usable bytes [464..511] to convey what state is represented
> in the memory layout.
> 
> First 8 bytes of the sw_usable_bytes[464..467] will be set to OS enabled xstate
> mask(which is same as the 64bit mask returned by the xgetbv's xCR0).

I'd like to see some macros or struct or something in some user-visible
header (ptrace-abi.h I guess?) that instruct userland where to find this
software-defined word.  The rest of the layout and meaning is specified by
the chip manuals and it's only a question of convenience if we want to help
userland out with those bits.  But the use of the reserved-for-software
area to store a bitmask (or whatever else Linux might put there in the
future) is entirely a Linux invention that needs to be a clear and explicit
part of this userland ABI format.

> +/*
> + * The xfpregs_active() routine is same as the fpregs_active() routine,

s/xfpregs_active/xstateregs_active/
s/is same/is the same/

> @@ -204,8 +209,6 @@ int xfpregs_set(struct task_struct *targ
>  	if (ret)
>  		return ret;
>  
> -	set_stopped_child_used_math(target);
> -

You didn't mention this change in a comment or log entry.
It looks like it's superfluous after init_fpu.  So this change
is right, but AFAICT it belongs in an entirely separate patch
and has nothing to do with xsave support.

> +int xstateregs_get(struct task_struct *target, const struct user_regset *regset,
> +		unsigned int pos, unsigned int count,
> +		void *kbuf, void __user *ubuf)
> +{
> +	int ret;
> +	int size = regset->n * regset->size;
[...]
> +		/*
> +		 * Copy the rest of xstate memory layout
> +		 */
> +		ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
> +					  xsave_hdr,
> +					  offsetof(struct xsave_struct,
> +						   xsave_hdr), size);

This calculation is unnecessary (though it doesn't hurt); you can just use
-1 here.  The arch user_regset.get and user_regset.set functions are not
required to worry about bogus arguments.  Their callers are required to
pass values that don't violate the .n, .size, and .align constraints in the
user_regset.

> +int xstateregs_set(struct task_struct *target, const struct user_regset *regset,
> +		  unsigned int pos, unsigned int count,
> +		  const void *kbuf, const void __user *ubuf)
> +{
> +	int ret;
> +	int size = regset->n * regset->size;
[...]
> +	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
> +				 &target->thread.xstate->xsave, 0, size);

Same here.

> +	[REGSET_XSTATE] = {
> +		.core_note_type = NT_X86_XSTATE,
> +		.size = sizeof(long), .align = sizeof(long),
[...]
> +	[REGSET_XSTATE] = {
> +		.core_note_type = NT_X86_XSTATE,
> +		.size = sizeof(u32), .align = sizeof(u32),

Isn't the xsave format is really the same for 32-bit and 64-bit?
All its components are naturally 64 bits or larger, right?

If that's correct, I think it would be better to make the 32 and 64 version
of the regset uniform with .size and .align being sizeof(u64).

> +u64 xstate_fx_sw_bytes[6];
> +void update_regset_xstate_info(unsigned int size, u64 xstate_mask)
> +{
> +#ifdef CONFIG_X86_64
> +	x86_64_regsets[REGSET_XSTATE].n = size / sizeof(long);
> +#endif
> +#if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
> +	x86_32_regsets[REGSET_XSTATE].n = size / sizeof(u32);
> +#endif

Just change these to / sizeof(u64) accordingly.


Thanks,
Roland

  parent reply	other threads:[~2010-02-10  1:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09 20:13 [patch v2 0/4] updated ptrace/core-dump patches for supporting xstate - V2 Suresh Siddha
2010-02-09 20:13 ` [patch v2 1/4] revert "x86: ptrace and core-dump extensions for xstate" Suresh Siddha
2010-02-09 22:54   ` [tip:x86/ptrace] Revert " tip-bot for Suresh Siddha
2010-02-09 20:13 ` [patch v2 2/4] x86, ptrace: regset extensions to support xstate Suresh Siddha
2010-02-09 22:54   ` [tip:x86/ptrace] x86, ptrace: Regset " tip-bot for Suresh Siddha
2010-02-10  1:30   ` Roland McGrath [this message]
2010-02-10 10:44     ` [patch v2 2/4] x86, ptrace: regset " Oleg Nesterov
2010-02-10 11:28   ` Oleg Nesterov
2010-02-10 15:43     ` Oleg Nesterov
2010-02-10 18:26       ` Roland McGrath
2010-02-10 14:18   ` Oleg Nesterov
2010-02-10 15:34     ` Oleg Nesterov
2010-02-09 20:13 ` [patch v2 3/4] x86, ptrace: prepare regset get/set routines for user specified lengths Suresh Siddha
2010-02-09 22:55   ` [tip:x86/ptrace] x86, ptrace: Prepare " tip-bot for Suresh Siddha
2010-02-10  1:32   ` [patch v2 3/4] x86, ptrace: prepare " Roland McGrath
2010-02-09 20:13 ` [patch v2 4/4] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET Suresh Siddha
2010-02-09 22:55   ` [tip:x86/ptrace] " tip-bot for Suresh Siddha
2010-02-10  1:52   ` [patch v2 4/4] " Roland McGrath
2010-02-10  2:03     ` H.J. Lu
2010-02-10  3:07       ` Roland McGrath
2010-02-10  4:24         ` H.J. Lu
2010-02-10 13:18   ` Oleg Nesterov
2010-02-10 19:12     ` Roland McGrath
2010-02-11  2:17       ` H. Peter Anvin
2010-02-11  3:30         ` Roland McGrath
2010-02-10  1:12 ` [patch v2 0/4] updated ptrace/core-dump patches for supporting xstate - V2 Roland McGrath
2010-02-10  1:22   ` Suresh Siddha
2010-02-10  7:27   ` Ingo Molnar
2010-02-10 18:58     ` Roland McGrath
2010-02-11  2:18       ` H. Peter Anvin
2010-02-11  3:45         ` Roland McGrath
2010-02-11  4:16           ` H. Peter Anvin

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=20100210013031.208FB73D8@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.