Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug

["H. Peter Anvin" <hpa@zytor.com>]

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