All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jinsong Liu <jinsong.liu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"keir@xen.org" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"haoxudong.hao@gmail.com" <haoxudong.hao@gmail.com>
Subject: Re: [PATCH 2/5] X86 architecture instruction set extension definiation
Date: Fri, 22 Nov 2013 11:31:51 +0000	[thread overview]
Message-ID: <528F40A7.7040904@citrix.com> (raw)
In-Reply-To: <528F4D570200007800105C2E@nat28.tlf.novell.com>

On 22/11/13 11:25, Jan Beulich wrote:
>>>> On 21.11.13 at 16:14, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 19/11/13 10:49, Liu, Jinsong wrote:
>>> @@ -327,14 +321,33 @@ unsigned int xstate_ctxt_size(u64 xcr0)
>>>      return ebx;
>>>  }
>>>  
>>> +static bool_t valid_xcr0(u64 xcr0)
>>> +{
>> Valid states in xcr0 ave very complicated, and are really not helped by
>> having the dependencies split across several manuals.
>>
>> I feel that for the sanity of someone trying to follow the code, there
>> should be comments, and bits are validated in position order.
>>
>> So,
>>
>> /* XSTATE_FP must be unconditionally set */
>>
>>> +    if ( !(xcr0 & XSTATE_FP) )
>>> +        return 0;
>>> +
>> /* XSTATE_YMM depends on XSTATE_SSE */
>>
>>> +    if ( (xcr0 & XSTATE_YMM) && !(xcr0 & XSTATE_SSE) )
>>> +        return 0;
>> /* XSTATE_BNDREGS and BNDCSR must be the same */
>> if ( (xcr0 & XSTATE_BNDREGS) ^ (xcr0 & XSTATE_BNDCSR) )
>>      return 0;
>>
>>
>> /* XSTATE_{OPMASK,ZMM,HI_ZMM} must be the same, and require XSTATE_YMM */
> Can be done of course (albeit I'm not inclined to change the
> ordering - I'd rather keep XMM/YMM/ZMM stuff together, and
> handle independent things separately).
>
>>> +
>>> +    if ( xcr0 & (XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM) )
>>> +    {
>>> +        if ( !(xcr0 & XSTATE_YMM) )
>>> +            return 0;
>>> +
>>> +        if ( ~xcr0 & (XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM) )
>>> +            return 0;
>>> +    }
>>> +
>> return 1;
> Why?

That was based on the re-ordering of BNDREGS/BNDCSR, but is subject to
the choice of reordering.

>
>> Shouldn't there also be a test against the xfeat_mask here, rather than
>> at all callers ?
> No, the purpose of the function is to validate a single set of flags
> for internal consistency. The way validate_xstate() works makes it
> so validating xcr0 against xfeature_mask is unnecessary (as xcr0
> is already verified to be a subset of xcr0_accum).

Ok.

>
>>> -#define XSTATE_ALL     (~0)
>>> -#define XSTATE_NONLAZY (XSTATE_LWP)
>>> +#define XSTATE_ALL     (~(1ULL << 63))
>> Why has XSTATE_ALL changed to ~XSTATE_LWP ?
> LWP is bit 62. Bit 63 is reserved.
>
> Jan
>

Oops - so it is.  In which case this change is certainly correct.

~Andrew

  reply	other threads:[~2013-11-22 11:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 10:49 [PATCH 2/5] X86 architecture instruction set extension definiation Liu, Jinsong
2013-11-21 15:14 ` Andrew Cooper
2013-11-22 11:25   ` Jan Beulich
2013-11-22 11:31     ` Andrew Cooper [this message]
2013-11-22 13:27 ` [PATCH v2 2/5] x86/xsave: enable support for new ISA extensions Jan Beulich
2013-11-22 14:48   ` George Dunlap
2013-11-22 15:47     ` Jan Beulich

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=528F40A7.7040904@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=haoxudong.hao@gmail.com \
    --cc=jinsong.liu@intel.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.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 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.