On Fri, Nov 22, 2019 at 10:44 AM Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Fri, Nov 22, 2019 at 09:20:39AM -0800, Dan Williams wrote: > > For those cases the thought would be to have memset512() for case1 and > > __iowrite512_copy() for case3. Where memset512() writes a > > non-incrementing source to an incrementing destination, and > > __iowrite512_copy() copies an incrementing source to an incrementing > > destination. Those 2 helpers *would* have fallbacks, but with the > > option to use something like cpu_has_write512() to check in advance > > whether those routines will fallback, or not. > > > > That can be a discussion for a future patchset when those users arrive. > > Oh, sure, of course. > > My only angle is very simple: if the MOVDIR* et al is only supported on > upcoming Intel platforms and looking at the use cases: > > 1. clear poison/MKTME > 3. copy iomem in big chunks > > I'm going to venture a guess that those two cases are going to be > happening only on Intel platforms which already support MODVIR*. So > wouldn't really need to do any generic helpers because those use cases > are very specific already. Which would make your feature detection a > one-time, driver-init time thing anyway... > > Unless I misunderstand those cases and there really is a use case > where the thing would fallback and the fallback would really be for an > "unenlightened" platform without that MOVDIR* hw support...? At least for something like __iowrite512_copy() it would indeed be something an unenlightened driver could call. Those drivers would simply be looking for opportunistic efficiency and could tolerate a fallback. Just like current __iowrite64_copy() users don't care if that routine falls back internally.
