From: "H. Peter Anvin" <hpa@zytor.com>
To: Denys Vlasenko <dvlasenk@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Brian Gerst <brgerst@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Borislav Petkov <bp@alien8.de>,
Andy Lutomirski <luto@amacapital.net>,
Oleg Nesterov <oleg@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Alexei Starovoitov <ast@plumgrid.com>,
Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/9] x86/asm/entry/32: tidy up some instructions
Date: Wed, 01 Apr 2015 13:57:09 -0700 [thread overview]
Message-ID: <551C5BA5.9010407@zytor.com> (raw)
In-Reply-To: <551C5A73.3050109@redhat.com>
On 04/01/2015 01:52 PM, Denys Vlasenko wrote:
> On 04/01/2015 05:50 PM, Linus Torvalds wrote:
>> On Wed, Apr 1, 2015 at 4:10 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
>>>
>>> I did not know that. I was sure they are always zero extended.
>>
>> On all half-way modern cpu's they are. But on some older cpu's
>> (possibly just the original 386) the segment move instructions
>> basically are always 16-bit, and the operand size is ignored (so the
>> 32-bit version is just smaller and faster to decode, because it
>> doesn't have a 16-bit operand size prefix)
>>
>> Iirc, the same is true for the values pushed to memory on exceptions,
>> so the 'cs/ss' values on the exception stack may not be reliable in
>> the upper 16 bits.
>>
>> I don't remember if the same might be true of "pushl %Sseg". The intel
>> architecture manual says segment registers are zero-extended on push.
>
> BTW, AMD64 docs do explicitly say that MOVs from segment registers
> to gpregs are zero-extending.
>
For Intel processors it is true for Pentium Pro and later processors, as
far as I know.
-hpa
next prev parent reply other threads:[~2015-04-01 20:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-31 17:00 [PATCH 1/9] x86/asm/entry/64: do not TRACE_IRQS fast SYSRET64 path Denys Vlasenko
2015-03-31 17:00 ` [PATCH 2/9] x86/asm/entry/32: Use PUSH instructions to build pt_regs on stack Denys Vlasenko
2015-04-01 8:51 ` Ingo Molnar
2015-04-01 13:12 ` Denys Vlasenko
2015-04-01 13:21 ` Ingo Molnar
2015-04-01 13:53 ` Borislav Petkov
2015-04-02 12:25 ` [tip:x86/asm] x86/asm/entry/32: Use smaller PUSH instructions instead of MOV, to build 'pt_regs' " tip-bot for Denys Vlasenko
2015-03-31 17:00 ` [PATCH 3/9] x86/asm/entry/64: simplify retint_kernel label usage, make retint_restore_args label local Denys Vlasenko
2015-04-02 12:25 ` [tip:x86/asm] x86/asm/entry/64: Simplify " tip-bot for Denys Vlasenko
2015-03-31 17:00 ` [PATCH 4/9] x86/asm/entry/64: remove redundant DISABLE_INTERRUPTS Denys Vlasenko
2015-04-02 12:25 ` [tip:x86/asm] x86/asm/entry/64: Remove redundant DISABLE_INTERRUPTS() tip-bot for Denys Vlasenko
2015-03-31 17:00 ` [PATCH 5/9] x86/asm/entry/64: simplify looping around preempt_schedule_irq Denys Vlasenko
2015-04-02 12:26 ` [tip:x86/asm] x86/asm/entry/64: Simplify looping around preempt_schedule_irq() tip-bot for Denys Vlasenko
2015-03-31 17:00 ` [PATCH 6/9] x86/asm/entry/64: tidy up some instructions Denys Vlasenko
2015-03-31 17:00 ` [PATCH 7/9] x86/asm/entry/32: " Denys Vlasenko
2015-03-31 22:21 ` Brian Gerst
2015-03-31 23:09 ` Linus Torvalds
2015-04-01 11:10 ` Denys Vlasenko
2015-04-01 15:50 ` Linus Torvalds
2015-04-01 20:52 ` Denys Vlasenko
2015-04-01 20:57 ` H. Peter Anvin [this message]
2015-04-01 22:14 ` Linus Torvalds
2015-04-02 0:32 ` Brian Gerst
2015-04-01 8:29 ` Ingo Molnar
2015-03-31 17:00 ` [PATCH 8/9] x86/asm: replace MOVQ $imm,%reg with MOVL Denys Vlasenko
2015-04-02 12:26 ` [tip:x86/asm] x86/asm: Replace "MOVQ $imm, %reg" " tip-bot for Denys Vlasenko
2015-03-31 17:00 ` [PATCH 9/9] x86/asm/entry/64: use local label to skip around sycall dispatch Denys Vlasenko
2015-04-02 12:26 ` [tip:x86/asm] x86/asm/entry/64: Use " tip-bot for Denys Vlasenko
2015-04-02 12:25 ` [tip:x86/asm] x86/asm/entry/64: Do not TRACE_IRQS fast SYSRET64 path tip-bot for Denys Vlasenko
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=551C5BA5.9010407@zytor.com \
--to=hpa@zytor.com \
--cc=ast@plumgrid.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=fweisbec@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=wad@chromium.org \
--cc=x86@kernel.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.