Ich kann mir kaum vorstellen, dass man jetzt auf einmal Instruktionen entfernt die DRM Maßnahmen nutzen, das wäre in den Vorgänger CPUs dann doch auch immer mal wieder der Fall gewesen und ist nie namentlich erwähnt worden.
Denke, dass es ein bigLittle Problem sein wird.
Die Lösung der "temporären" Deaktivierung wäre aber schon irgendwie ein Armutszeugnis für Intel, hier sollte man dann doch bitte schnellstmöglich einen Softwareschalter einbauen.
Wenn nur die Hybrid Technology das Problem sein soll, wäre dies keine, wenn man die Kerne temporär deaktiviert.
Darüber hinaus, in den ISAs werden immer wieder Befehle auf deprecated gesetzt und verschwinden dann in späteren Versionen relativ unbemerkt aus dem Design. Auch bei den älteren Zen's gab es bspw. einige explizit für veraltet erklärte Befehle, die zu der Zeit aktuelle Software immer noch nutzte.
Einige Kopierschutz/DRM-Software kann sich hier bspw. durchaus bewusst auf exotische Befehle stützen, bspw. um zu vermeiden, dass sie virtualisiert oder emuliert wird, etc. Da lassen sich die jeweiligen Hersteller natürlicherweise nicht in die Karten schauen, denn ansonsten wüsste man auch direkt, wie man derartige SW aushebeln kann. Wird man abwarten müssen.
Größere Architekturwechsel bergen immer Risiken für die weiterverwendung alter Software ... wie gesagt, wenn aber die Hybrid Technology das "Problem" sein sollte, dürfte sich das leicht umgehen lassen. Warum diese das Problem sein könnte? Weil die ISA zwar weitestgehend angeglichen ist, es aber dennoch diffizile Unterschiede zwischen den Kernen gibt und es auf den E-Kernen (früher Atoms) einige wenige andere Befehle als auf den großen Kernen gibt und umgekehrt, was aber i. d. R. bestenfalls für Systemsoftware relevant ist. Man könnte jetzt weiter spekulieren und überlegen, dass wenn ein DRM-Thread bspw. zuerst auf einem Golden Cove läuft und dann auf einen Gracemont umgelegt wird (nachdem er seine ISA-Erkennung schon längst abgeschlossen hat), könnte er versuchen ein paar exotischere low-level Befehle anzusprechen, die plötzlich "verschwunden" sind und das würde natürlich zu Problemen führen.
Armutszeugnis seitens Intel, nö, warum sollte es? Das ist komplett neue Technologie. Wenn man erwarten würde, dass auch ein heutiger, moderner Mikroprozessor noch bis in kleinste Detail vollends abwärtkompatibel zu CPUs aus den 80ern wäre, wären wir nich beim heutigen Leistungsniveau angekommen und die Designs wären vermutlich noch deutlich fehleranfälliger. Ab einer gewissen Entwicklungsstufe gilt es alte Zöpfe abzuschneiden, sonst kommt man entwicklungstechnisch nicht merklich weiter bzw. bleibt deutlich hinter den Möglichkeiten zurück.
Und wie gesagt, sollte es mit dem temporären Deaktivieren der Gracemont-Kerne (muss man ja nicht, es wird gar auch Varianten ohne diese geben) tatsächlich getan sein, würde alte SW dennoch größtenteils besser auf den Golden Cove-Kernen laufen als jemals zuvor, weil das voraussichtlich die derzeit durchsatzstärkste Mirkoarchitektur ist und anscheinend noch gepaart mit dem derzeit höchsten Takt (bei den großen CPUs). Ob es wirklich "so einfach" ist, wird man natürlich noch abwarten müssen. Dass Intel hier vorwarnt ist nur sinnvoll und vermutlich auch rechtlich angeraten.
Ergänzend: Ob es vielleicht ein "Thread-Pinning-Tool" von Intel oder gar Microsoft geben wird bleibt abzuwarten. Ich hätte auch auf so etwas als Migrationsunterstützung hin vermutet, denn wie könnte man ansonsten am einfachsten bei alter SW allen Problemen aus dem Weg gehen, indem man einfach definiert, dass bspw. alle an der MeinSpiel.exe hängenden Prozesse und Threads grundsätzlich nur auf Golden Cove-Kernen zu platzieren sind. Ob eine derartiger Ansatz aber tatsächlich alle Probleme zu lösen vermag weiß ich nicht. Alle Eventualitäten inkludierend würde ich grundsätzlich auf ein "Nein" tippen, denn einige SW verwendet die ISA nicht unbedingt so wie vom CPU-Hersteller vorgesehen, sei es nur, weil man das letzte Quentchen Performance herausholen will oder aber man sich als Entwickler für besonders geistreich hält oder aber weil man bewusst sehr speziellen und HW-abhängigen Code schreiben will, sei es um die Lauffähigkeit einzuschränken oder bspw. ein Reverseengeneering zu erschweren oder was auch immer.