Re: SMP support for 680[34]0 ?

Le dim. 7 janv. 2024 à 04:15, Izumi Tsutsui <[email protected]> a écrit :
> Well, maybe I should say it "boring and non-motivated work"
> rather than "complex".

I wonder if that's better or worse :-)

> Of course the MI (machine independent) part of NetBSD has enough SMP
> support, but I'm afraid many sources in the m68k MD (machine dependent)
> part like src/sys/arch/m68k/m68k/pmap_motorola.c and
> src/sys/arch/[MACHINE]/[MACHINE]/pmap_bootstrap.c etc. assumed
> there was no SMP support.

Figures. I would have to have a first step of supporting my design UP to
get the machine-specific bootstrap. Then figure out how to move from
that to hopefully MP someday.

I'm planning to ignore cache issues at first, by  disabling caches entirely
(good bye, performance!) - including having a physical switch to assert
/CDIS in case that's needed for early work.
No cache, no cache coherency, no problems :-)

> If qemu supports "real" SMP support it might be an interesting work
> to implement it, but I wonder if qemu (and other emulators) will
> implement critical race conditions and data/instruction caches
> where most complex part of SMP support

SMP support for m68k in QEmu would be awesome, in particular if
it supports multithreading on the host the way the Arrm or RISC-V
version do. Much faster build! Even in the non-multithreaded way
(looking at you, SPARC) it would be nice to have... on the way to
multithreaded ;-) Unfortunately, I don't think it's there? I didn't
look at the new virt68k machine, I must confess.

I don't think simulating cache issues in QEmu is important. Caches
can be ignored (/CDIS, cache control register, or bits in the page
maps) at first, Then figure out how to claw back some performance.
IMHO the SW sould be sorted out first so that it works in an 'ideal'
hardware environment. Then the real hardware issues can be
addressed.

SMP on the 68k and caches won't play nice anyway:

- the 68020 doesn't have data cache (but 68551 are impossible to
  find and awkward to use, so not considering that), so that one's easy
- the 68030 has no snooping ability at all, so shared pages will
  likely need to be cache-inhibited (which in a modern OS is akin
  to all pages! unless one can figure out if a given process doesn't
  have threads so the private pages could be cached?)
- the 68040 has snooping (update or invalidate), but doesn't
  broadcast writes that hit in L1D. UM says to set shared pages to
  write-through instead of write-back. Write-back might work with
  snoop-invalidate? Not likely (see '060) but might be the most
  interesting to play with.
- the 68060 is similar to the 68040, minus snoop-update. They still
  recommend write-through for shared pages.

Cordially,

-- 
Romain Dolbeau