lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug
Mathieu Desnoyers wrote:
>
> I'm just worried about this comment from Harvey Harrison :
>
> arch/x86/mm/fault.c : is_prefetch()
>
> * Values 0x26,0x2E,0x36,0x3E are valid x86 prefixes.
> * In X86_64 long mode, the CPU will signal invalid
> * opcode if some of these prefixes are present so
> * X86_64 will never get here anyway
> */
>
> This comment refers to :
>
> 0x26 : ES segment override prefix
> 0x2E : CS segment override prefix
> 0x36 : SS segment override prefix
> 0x3E : DS segment override prefix
>
> AMD documentation seems to indicate that these prefix will be null, not
> that the cpu would signal "invalid opcodes" :
>
> "AMD 64-Bit Technology" A.7
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf
>
> "In 64-bit mode, the DS, ES, SS and CS segment-override prefixes have no effect.
> These four prefixes are no longer treated as segment-override prefixes in the
> context of multipleprefix rules. Instead, they are treated as null prefixes."
>
> Intel does not seem to state anything particular about these prefixes
> for the 64-bit mode.
>
> So, is this comment misleading, or is it using the term "invalid opcode"
> in a way that does not imply generating a fault ?
>

They do not signal faults, there just aren't any base addresses behind
them. Some AMD chips allow limits to be set on these segments --
apparently added on behalf of some hypervisor makers; I suspect that
VMX/SVM is making that quickly obsolete.

So it should be just fine.

Acked-by: H. Peter Anvin <hpa@zytor.com>

-hpa



\
 
 \ /
  Last update: 2008-08-14 22:51    [W:0.146 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site