Re: [PATCH gnumach] smp: Remove hardcoded AP_BOOT_ADDR

[Samuel Thibault]

Hello,

Jessica Clarke, le mar. 30 janv. 2024 16:07:29 +0000, a ecrit:
> On 30 Jan 2024, at 09:02, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > 
> > Jessica Clarke, le mar. 30 janv. 2024 02:32:07 +0000, a ecrit:
> >> On 29 Jan 2024, at 10:20, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> >>> 
> >>> Damien Zammit, le lun. 29 janv. 2024 10:07:30 +0000, a ecrit:
> >>>> - ljmp $BOOT_CS, $M(0f)
> >>>> + xorl %eax, %eax
> >>>> + mov %cs, %ax
> >>>> + shll $4, %eax
> >>>> + addl $M(0f), %eax
> >>>> + movl %eax, M(ljmp_offset32)
> >>> 
> >>> This won't work with pipelined processors, which assume a complete
> >>> separation between code and data, and will thus have already loaded
> >>> the jmp instruction before your modify it.
> >> 
> >> That’s true of most architectures, but not x86. It architecturally
> >> guarantees that self-modifying code works,
> > 
> > ?? It was a very common way to detect pentium processors, back in the
> > time.
> 
> Ok, so I went and read 12.6 Self-Modiyfing Code of the Intel SDM Volume
> 3A (from December 2023), and it has this to say:

I also got a look at my (bit older) volume 3 (dated november 2020), and
it says (section 8.1.3 Handling Self- and Cross-Modifying Code)

“
IA-32 processors exhibit model-specific behavior when executing
self-modified code, depending upon how far ahead of the current
execution pointer the code has been modified.

As processor microarchitectures become more complex and start to
speculatively execute code ahead of the retire- ment point (as in P6 and
more recent processor families), the rules regarding which code should
execute, pre- or post-modification, become blurred.
”

It also mentions the jmp trick as a way that is compliant with current
and future versions of IA-32. But it also says that it “is not
required for programs intended to run on the Pentium or Intel486
processors, but are recommended to ensure compatibility with the P6 and
more recent processor families” (which is contrary to what we could
infer from the piece you quoted...)

> > A write to a memory location in a code segment that is currently cached
> > in the processor causes the associated cache line (or lines) to be
> > invalidated.

That looks like significantly expensive snooping. I wouldn't be
surprised that some cheap x86 clones don't implement this when
self-modifying code is frowned upon nowadays anyway.

> >>> Rather either perform the relocation from the C code,
> >> 
> >> Were your statement true, that wouldn’t fix the problem,
> > 
> > Isn't an IPI a synchronizing thing?
> 
> Oh that’s true,

Ok :)

I'd really rather depend on that (since it does make sense in the
happens-before questions).

Samuel