UPD Timer frequency

documentation/linux_configuration.tex

@@ -1773,4 +1773,343 @@ CONFIG\_X86\_MCE\_AMD [=y] \textbf{[N]}\\
 Zusätzliche Unterstützung für AMD-spezifische MCE-Funktionen wie den
 DRAM-Fehlerschwellenwert (DRAM Error Threshold).
 
+\subsection{Machine check injector support}
+CONFIG\_X86\_MCE\_INJECT [=m] \textbf{[M]}\\
+Unterstützung bei der Einspeisung von Maschinenprüfungen zu Testzwecken. Wenn Sie nicht wissen,
+was eine Maschinenprüfung ist und Sie keine Kernel-Qualitätssicherung durchführen, können Sie
+mit Sicherheit N sagen, also nein.
+
+\subsection{Performance monitoring \texorpdfstring{$\rightarrow$}{->}}
+Leistungsüberwachung
+
+\subsubsection{Intel uncore performance events}
+CONFIG\_PERF\_EVENTS\_INTEL\_UNCORE [=m] \textbf{[M]}\\
+Unterstützung für Intel-Uncore-Leistungsereignisse. Diese sind auf NehalemEX
+und moderneren Prozessoren verfügbar.
+
+\subsubsection{Intel/AMD rapl performance events}
+CONFIG\_PERF\_EVENTS\_INTEL\_RAPL [=m] \textbf{[M]}\\
+Unterstützung für Intel- und AMD-RAPL-Leistungsereignisse zur
+Leistungsüberwachung auf modernen Prozessoren.
+
+\subsubsection{Intel cstate performance events}
+CONFIG\_PERF\_EVENTS\_INTEL\_CSTATE [=m] \textbf{[M]}\\
+Einbeziehung der Unterstützung für Intel cstate performance events für die
+Leistungsüberwachung auf modernen Prozessoren.
+
+\subsubsection{AMD Processor Power Reporting Mechanism}
+CONFIG\_PERF\_EVENTS\_AMD\_POWER [=m] \textbf{[M]}\\
+Unterstützung von Stromversorgungsberichten für AMD-Prozessoren.\\
+Derzeit wird die Schnitt\-stel\-le X86\_FEATURE\_ACC\_POWER
+(CPUID Fn8000\_0007\_EDX[12]) genutzt,
+um den durchschnittlichen Stromverbrauch von Prozessoren der Familie 15h zu
+berechnen. 
+
+\subsubsection{AMD Uncore performance events}
+CONFIG\_PERF\_EVENTS\_AMD\_UNCORE [=m] \textbf{[M]}\\
+Unterstützung für AMD-Uncore-Leistungsereignisse für die Verwendung mit z.B.\\
+\texttt{perf stat -e amd\_l3/.../,amd\_df/.../}.\\
+Um diesen Treiber als Modul zu kompilieren, wählen Sie hier M: das Modul wird \texttt{amd-uncore} genannt.
+
+\subsubsection{AMD Zen3 Branch Sampling support}
+CONFIG\_PERF\_EVENTS\_AMD\_BRS [=y] \textbf{[Y]}\\
+Aktivieren Sie die AMD Zen3 Branch Sampling-Unterstützung (BRS), die bis zu 16 aufeinanderfolgende
+Verzweigungen in Registern erfasst.
+
+\subsubsection{IOPERM and IOPL Emulation}
+CONFIG\_X86\_IOPL\_IOPERM [=y] \textbf{[Y]}\\
+Dies ermöglicht die ioperm()- und iopl()-Systemaufrufe, die für Legacy-Anwendungen erforderlich sind.
+Bei der Legacy-IOPL-Unterstützung handelt es sich um einen weitreichenden Mechanismus, der es dem Userspace
+ermöglicht, neben dem Zugriff auf alle 65536 E/A-Ports auch Interrupts zu deaktivieren. Um diesen Zugriff
+zu erhalten, benötigt der Aufrufer CAP\_SYS\_RAWIO-Fähigkeiten und die Erlaubnis von potenziell aktiven
+Sicherheitsmodulen. Die Emulation schränkt die Funktionalität des Syscalls auf den Zugriff auf alle E/A-Ports
+ein, verhindert aber die Möglichkeit, Interrupts aus dem Userspace zu deaktivieren, was bei Verwendung des
+Hardware-IOPL-Mechanismus möglich wäre.
+
+\subsubsection{Late microcode loading (DANGEROUS)}
+CONFIG\_MICROCODE\_LATE\_LOADING [=n] \textbf{[N]}\\
+Das späte Laden von Mikrocode, wenn das System bereits läuft und Befehle ausführt, ist eine heikle
+Angelegenheit und sollte nach Möglichkeit vermieden werden. Allein die Abfolge der Synchronisierung
+aller Kerne und SMT-Threads ist ein zerbrechlicher Tanz, der nicht garantiert, dass die Kerne nach
+dem Laden nicht softlocking werden. Daher sollten Sie dies auf eigenes Risiko tun. Das späte Laden
+färbt auch den Kernel.
+
+\subsubsection{/dev/cpu/*/msr - Model-specific register support}
+CONFIG\_X86\_MSR [=y] \textbf{[Y]}\\
+Dieses Gerät ermöglicht privilegierten Prozessen den Zugriff auf die modellspezifischen x86-Register (MSRs).\\
+Es ist ein Zeichengerät mit Major 202 und Minors 0 bis 31 für
+\texttt{/dev/cpu/0/msr} bis \texttt{/dev/cpu/31/msr}.
+MSR-Zugriffe sind bei Multiprozessorsystemen an eine bestimmte CPU gerichtet.
+
+\subsubsection{/dev/cpu/*/cpuid - CPU information support}
+CONFIG\_X86\_CPUID [=y] \textbf{[Y]}\\
+Dieses Gerät ermöglicht Prozessen den Zugriff auf den x86 CPUID-Befehl, der auf einem bestimmten Prozessor
+ausgeführt werden soll. Es handelt sich um ein Zeichengerät mit Major 203 und Minors 0 bis 31 für
+\texttt{/dev/cpu/0/cpuid} bis \texttt{/dev/cpu/31/cpuid}.
+
+\subsubsection{Enable 5-level page tables support}
+CONFIG\_X86\_5LEVEL [=y] \textbf{[Y]}\\
+5-Level-Paging ermöglicht den Zugriff auf einen größeren Adressraum:
+bis zu 128~PiB virtueller Adressraum und 4~PiB physikalischer Adressraum. Es wird von zukünftigen Intel-CPUs
+unterstützt werden. Ein Kernel mit aktivierter Option kann auf Rechnern gebootet werden, die 4- oder 5-Level-Paging
+unterstützen. Siehe Documentation/arch/x86/x86\_64/5level-paging.rst für weitere Informationen.\\
+Sagen Sie N, wenn Sie unsicher sind.
+
+\subsubsection{Enable statistic for Change Page Attribute}
+CONFIG\_X86\_CPA\_STATISTICS [=y] \textbf{[Y]}\\
+Statistiken über den Mechanismus zum Ändern von Seitenattributen offenlegen, der dabei hilft,
+die Wirksamkeit der Erhaltung großer und umfangreicher Seitenzuordnungen zu bestimmen,
+wenn Zuordnungsschutzmaßnahmen geändert werden.
+
+\subsubsection{AMD Secure Memory Encryption (SME) support}
+CONFIG\_AMD\_MEM\_ENCRYPT [=y] \textbf{[N]}\\
+Sagen Sie Ja, um die Unterstützung für die Verschlüsselung des Systemspeichers zu aktivieren.
+Dies erfordert einen AMD-Prozessor, der Secure Memory Encryption (SME) unterstützt.
+
+\paragraph{Activate AMD Secure Memory Encryption (SME) by default}$~$\\
+CONFIG\_AMD\_MEM\_ENCRYPT\_ACTIVE\_BY\_DEFAULT [=n] \textbf{[N]}\\
+Sagen Sie Ja, damit der Systemspeicher standardmäßig verschlüsselt wird, wenn er auf einem
+AMD"=Pro\-zes\-sor läuft, der Secure Memory Encryption (SME) unterstützt.
+Wenn Sie Y wählen, kann die Verschlüsselung des Systemspeichers mit der Befehlszeilenoption
+\texttt{mem\_encrypt=off} deaktiviert werden. Ist der Wert auf N gesetzt, kann die Verschlüsselung
+des Systemspeichers mit der Befehlszeilenoption \texttt{mem\_encrypt=on} aktiviert werden.
+
+\subsubsection{NUMA Memory Allocation and Scheduler Support}
+CONFIG\_NUMA [=y] \textbf{[Y]}\\
+Aktivieren Sie die NUMA-Unterstützung (Non-Uniform Memory Access). Der Kernel wird versuchen, den
+von einer CPU verwendeten Speicher dem lokalen Speicher-Controller der CPU zuzuweisen und dem Kernel
+mehr Kenntnis über NUMA zu geben.\\
+Für 64-Bit wird dies empfohlen, wenn das System Intel Core i7 (oder höher),
+AMD Opteron oder EM64T NUMA ist.\\
+Für 32-Bit ist dies nur erforderlich, wenn Sie einen 32-Bit-Kernel auf einer 64-Bit-NUMA-Plattform booten.
+Andernfalls sollten Sie N angeben.
+
+\paragraph{Old style AMD Opteron NUMA detection}$~$\\
+CONFIG\_AMD\_NUMA [=y] \textbf{[N]}\\
+Aktivieren Sie die Erkennung der AMD NUMA-Knoten-Topologie. Wenn Sie ein AMD-Multi\-pro\-zes\-sor\-system haben,
+sollten Sie hier Y angeben. Dies verwendet eine alte Methode, um die NUMA-Konfiguration direkt von der
+eingebauten Northbridge des Opteron zu lesen.\\
+Es wird empfohlen, stattdessen
+X86\_64\_ACPI\_NUMA zu verwenden,
+das auch Priorität hat, wenn beide einkompiliert sind.
+
+\paragraph{ACPI NUMA detection}$~$\\
+CONFIG\_X86\_64\_ACOU\_NUMA [=y] \textbf{[Y]}\\
+Aktivieren Sie die auf ACPI SRAT basierende Knoten-Topologie-Erkennung.
+
+\paragraph{NUMA emulation}$~$\\
+CONFIG\_NUMA\_EMU [=n] \textbf{[N]}\\
+Aktivieren Sie die NUMA-Emulation. Eine flache Maschine wird in virtuelle Knoten aufgeteilt, wenn sie mit
+\texttt{numa=fake=N} gebootet wird, wobei N die Anzahl der Knoten ist.
+Dies ist nur für die Fehlersuche nützlich.
+
+\paragraph{Maximum NUMA Nodes (as a power of 2)}$~$\\
+CONFIG\_NODES\_SHIFT [=5]  \textbf{[5]}\\
+(Maximale NUMA-Knoten (als eine Potenz von 2))\\
+Geben Sie die maximale Anzahl der auf dem Zielsystem verfügbaren NUMA-Knoten an.
+Erhöht den reservierten Speicherplatz für verschiedene Tabellen.
+
+\subsubsection{Enable sysfs memory/probe interface}
+CONFIG\_ARCH\_MEMORY\_PROBE [=n] \textbf{[N]}\\
+Diese Option aktiviert eine sysfs-Speicher/Probe-Schnittstelle für Tests.\\
+Siehe Documentation/admin-guide/mm/memory-hotplug.rst für weitere Informationen.
+Wenn Sie unsicher sind, wie Sie diese Frage beantworten sollen, antworten Sie mit N.
+
+\subsubsection{Support non-standard NVDIMMs and ADR protected memory}
+CONFIG\_X86\_PMEM\_LEGACY [=m] \textbf{[M]}\\
+Behandeln Sie Speicher, der mit dem nicht standardmäßigen e820-Typ von 12 markiert ist, wie er vom
+Intel Sandy Bridge-EP Referenz-BIOS verwendet wird, als geschützten Speicher.
+Der Kernel bietet diese Regionen dem \texttt{pmem}-Treiber an, so dass sie für persistenten Speicher
+verwendet werden können.\\
+Sagen Sie Y, wenn Sie unsicher sind.
+
+\subsubsection{Check for low memory corruption}
+CONFIG\_X86\_CHECK\_BIOS\_CORRUPTION [=y] \textbf{[Y]}\\
+Regelmäßige Überprüfung auf Speicherbeschädigung im niedrigen Speicher, die vermutlich durch das BIOS
+verursacht wird. Auch wenn dies in der Konfiguration aktiviert ist, zur Laufzeit ist es deaktiviert.
+Aktivieren Sie es, indem Sie \texttt{memory\_corruption\_check=1} in der Kernel-Befehlszeile eingeben.
+Standardmäßig werden die unteren 64~k des Speichers alle 60 Sekunden überprüft; siehe die Parameter
+\texttt{memory\_corruption\_check\_size} und \texttt{memory\_corruption\_check\_period} in
+Documentation/admin-guide/kernel-parameters.rst, um dies anzupassen.
+Wenn diese Option mit den Standardparametern aktiviert ist, hat sie so gut wie keinen Overhead, da sie
+eine relativ kleine Menge an Speicher reserviert und diesen nur selten durchsucht. Sie erkennt Korruption
+und verhindert, dass sie das laufende System beeinträchtigt. Sie ist jedoch als Diagnosewerkzeug gedacht;
+wenn eine wiederholte BIOS-verursachte Beschädigung stets denselben Speicher betrifft, können Sie
+\texttt{memmap=} verwenden, um zu verhindern, dass der Kernel diesen Speicher verwendet.\\[1em]
+\noindent\fbox{%
+	\parbox{445\unitlength}{Hinweis: Kann ausgeschaltet werden, wenn im \texttt{journalctl} niemals
+	\glqq corrupted low memory\grqq{} erscheint.}
+}
+
+\paragraph{Set the default setting of memory\_corruption\_check}$~$\\
+CONFIG\_X86\_BOOTPARAM\_MEMORY\_CORRUPTION\_CHECK [=y] \textbf{[Y]}\\
+Legt fest, ob der Standardstatus von \texttt{memory\_corruption\_check} ein- oder ausgeschaltet ist.
+
+\subsubsection{MTRR (Memory Type Range Register) support}
+CONFIG\_MTRR [=y] \textbf{[Y]}\\
+Bei Prozessoren der Intel P6-Familie (Pentium Pro, Pentium II und später) können die Memory Type Range Register (MTRRs)
+verwendet werden, um den Zugriff des Prozessors auf Speicherbereiche zu steuern. Dies ist besonders nützlich, wenn Sie
+eine Videokarte (VGA) an einem PCI- oder AGP-Bus haben. Durch die Aktivierung von Write-Combining können
+Bus-Schreibübertragungen zu einer größeren Übertragung kombiniert werden, bevor sie über den PCI/AGP-Bus geleitet
+werden. Dies kann die Leistung von Bildschreiboperationen um das 2,5-fache oder mehr erhöhen.
+Wenn Sie hier Y angeben, wird eine /proc/mtrr-Datei erstellt, die zur Manipulation der MTRRs Ihres Prozessors verwendet
+werden kann. Normalerweise sollte der X-Server dies verwenden.\\
+Dieser Code hat eine recht generische Schnittstelle, so dass ähnliche Steuerregister auf anderen Prozessoren ebenfalls
+leicht unterstützt werden können:\\
+Die Prozessoren Cyrix 6x86, 6x86MX und M II verfügen über Address Range Registers (ARRs), die eine ähnliche
+Funktionalität wie MTRRs bieten. In diesen Fällen werden die ARRs zur Emulation der MTRRs verwendet.
+Die AMD-Prozessoren K6-2 (Stepping 8 und höher) und K6-3 haben zwei MTRRs. Der Centaur C6 (WinChip) hat 8 MCRs, die
+Schreibkombinationen ermöglichen. Alle diese Prozessoren werden von diesem Code unterstützt und es ist sinnvoll, hier
+Y anzugeben, wenn Sie einen dieser Prozessoren haben.\\
+Die Angabe von Y an dieser Stelle behebt auch ein Problem mit fehlerhaften SMP-BIOSen, die die MTRRs nur für die
+Boot-CPU und nicht für die sekundären CPUs setzen. Das kann zu allen möglichen Problemen führen, also ist es gut,
+hier Y zu sagen.\\
+Sie können sicher Y sagen, auch wenn Ihr Rechner keine MTRRs hat, Sie werden nur etwa 9 KB zu Ihrem Kernel hinzufügen.
+Siehe $<$file:Documentation/arch/x86/mtrr.rst$>$ für weitere Informationen.
+
+\paragraph{MTRR cleanup support}$~$\\
+CONFIG\_MTRR\_SANITIZER [=y] \textbf{[Y]}\\
+Umwandlung des MTRR-Layouts von kontinuierlich in diskret, damit X-Treiber Rückschreibeinträge hinzufügen können.
+Kann mit \texttt{disable\_mtrr\_cleanup} in der Kernel-Kommandozeile deaktiviert werden.
+Die größte MTRR-Eintragsgröße für einen kontinuierlichen Block kann mit \texttt{mtrr\_chunk\_size} festgelegt werden.\\
+Wenn Sie unsicher sind, sagen Sie Y.
+
+\paragraph{MTRR cleanup enable value (0-1)}$~$\\
+CONFIG\_MTRR\_SANITIZER [=1] \textbf{[1]}\\
+Aktivieren Sie den \glqq mtrr cleanup\grqq{}-Standardwert
+
+\paragraph{MTRR cleanup spare reg num (0-7)}$~$\\
+CONFIG\_MTRR\_SANITIZER\_SPARE\_REG\_NR\_DEFAULT [=0] \textbf{[0]}\\
+MTRR cleanup spare entries Defaulteintrag, dies kann über
+\texttt{mtrr\_spare\_reg\_nr=N} auf der Kernel-Be\-fehls\-zei\-le geändert werden.
+
+\subsubsection{Indirect Branch Tracking}
+CONFIG\_X86\_KERNEL\_IBT [=y] \textbf{[Y]}\\
+Bauen Sie den Kernel mit Unterstützung für Indirect Branch Tracking auf, eine Hardware-Unterstützung, die die Integrität
+des Kontrollflusses an den Rändern schützt. Sie erzwingt, dass alle indirekten Aufrufe auf einer ENDBR-Anweisung landen
+müssen, und der Compiler wird den Code mit ihnen instrumentieren, damit dies geschieht.\\
+Zusätzlich zur Erstellung des Kernels mit IBT werden alle Funktionen, die keine indirekten Aufrufziele sind, versiegelt,
+um zu verhindern, dass sie jemals zu solchen werden.\\
+Dies erfordert LTO wie objtool-Läufe und verlangsamt den Bau. Es reduziert jedoch die Anzahl der ENDBR-Anweisungen im
+Kernel-Image erheblich.
+
+\subsubsection{Memory Protection Keys}
+CONFIG\_X86\_INTEL\_MEMORY\_PROTECTION\_KEYS [=y] \textbf{[Y]}\\
+Memory Protection Keys bietet einen Mechanismus zur Erzwingung seitenbasierter Schutzmaßnahmen, ohne dass die
+Seitentabellen geändert werden müssen, wenn eine Anwendung ihre Schutzdomänen ändert. Einzelheiten siehe
+Documentation/core-api/protection-keys.rst\\
+Wenn Sie unsicher sind, sagen Sie Y.
+
+\subsubsection{TSX enable mode () \texorpdfstring{$\rightarrow$}{->}}
+CONFIG\_X86\_INTEL\_MEMORY\_PROTECTION\_KEYS [=y] \textbf{[Y]}\\
+Intels TSX-Funktion (Transactional Synchronization Extensions) ermöglicht die Optimierung von Sperrprotokollen durch
+Lock Elision, was zu einer spürbaren Leistungssteigerung führen kann.
+Andererseits hat sich gezeigt, dass TSX für Seitenkanalangriffe (z. B. TAA) ausgenutzt werden kann, und es ist
+wahrscheinlich, dass in Zukunft weitere Angriffe dieser Art entdeckt werden.
+Daher ist TSX standardmäßig nicht aktiviert (aka \texttt{tsx=off}). Ein Administrator kann diese Entscheidung durch den
+Befehlszeilenparameter \texttt{tsx=on} außer Kraft setzen.
+Auch wenn TSX aktiviert ist, versucht der Kernel, die bestmögliche TAA-Abschwächung zu aktivieren, je nach dem für
+den jeweiligen Rechner verfügbaren Mikrocode.
+Mit dieser Option kann der Standard-Tsx-Modus zwischen \texttt{tsx=on}, \texttt{=off} und \texttt{=auto}
+eingestellt werden. Siehe
+Documentation/admin-guide/kernel-parameters.txt für weitere Details.
+Sagen Sie off, wenn Sie sich nicht sicher sind, auto, wenn TSX in Gebrauch ist, aber auf sicheren Plattformen
+verwendet werden sollte, oder on, wenn TSX in Gebrauch ist und der Sicherheitsaspekt von tsx nicht relevant ist.
+
+\paragraph{off}$~$\\
+CONFIG\_X86\_INTEL\_TSX\_MODE\_OFF [=n] \textbf{[N]}\\
+TSX ist, wenn möglich, deaktiviert -- entspricht dem Befehlszeilenparameter \texttt{tsx=off}.
+
+\paragraph{on}$~$\\
+CONFIG\_X86\_INTEL\_TSX\_MODE\_ON [=n] \textbf{[N]}\\
+TSX ist auf TSX-fähiger Hardware immer aktiviert -- gleichbedeutend
+mit dem Befehlszeilenparameter \texttt{tsx=on}
+
+\paragraph{auto}$~$\\
+CONFIG\_X86\_INTEL\_TSX\_MODE\_AUTO [=y] \textbf{[Y]}\\
+TSX wird auf TSX-fähiger Hardware aktiviert, die als sicher gegen Seitenkanalangriffe gilt -- gleichbedeutend
+mit dem Befehlszeilenparameter \texttt{tsx=auto}.
+
+\subsubsection{Software Guard eXtensions (SGX)}
+CONFIG\_X86\_SGX [=y] \textbf{[Y]}\\
+Intel(R) Software Guard eXtensions (SGX) ist eine Reihe von CPU-Befehlen, die von Anwendungen verwendet werden
+können, um private Code- und Datenbereiche, die so genannten Enklaven, zu reservieren. Auf den privaten Speicher
+einer Enklave kann nur von Code zugegriffen werden, der innerhalb der Enklave läuft. Zugriffe von außerhalb der
+Enklave, einschließlich anderer Enklaven, werden von der Hardware nicht zugelassen.\\
+Wenn Sie unsicher sind, sagen Sie N.
+
+\subsubsection{X86 userspace shadow stack}
+CONFIG\_X86\_USER\_SHADOW\_STACK [=y] \textbf{[Y]}\\
+Der Schattenstapelschutz ist eine Hardwarefunktion, die eine Beschädigung der Rücksprungadresse einer Funktion
+erkennt. Dies hilft, ROP-Angriffe abzuschwächen. Anwendungen müssen aktiviert sein, um sie zu nutzen, und der
+alte Userspace erhält den Schutz nicht "umsonst". CPUs, die Shadow Stacks unterstützen, wurden erstmals im
+Jahr~2020 vorgestellt. Weitere Informationen finden Sie unter Documentation/arch/x86/shstk.rst.\\
+Wenn Sie unsicher sind, sagen Sie N.
+
+\subsubsection{EFI runtime service support}
+CONFIG\_EFI [=y] \textbf{[Y]}\\
+Dies ermöglicht es dem Kernel, verfügbare EFI-Laufzeitdienste (wie die EFI-Variablendienste) zu nutzen.\\
+Diese Option ist nur auf Systemen mit EFI-Firmware sinnvoll. Außerdem sollten Sie den neuesten ELILO-Lader
+verwenden, der unter \url{http://elilo.sourceforge.net} verfügbar ist, um die Vorteile der
+EFI-Laufzeitdienste zu nutzen. Aber auch mit dieser Option sollte der resultierende Kernel weiterhin auf
+bestehenden Nicht-EFI-Plattformen booten.
+
+\paragraph{EFI stub support}$~$\\
+CONFIG\_EFI\_STUB [=y] \textbf{[Y]}\\
+Mit dieser Kernel-Funktion kann ein bzImage direkt von der EFI-Firmware geladen werden, ohne dass ein
+Bootloader erforderlich ist.\\
+Weitere Informationen finden Sie unter Documentation/admin-guide/efi-stub.rst.
+
+\subparagraph{EFI handover protocol (DEPRECATED)}$~$\\
+CONFIG\_EFI\_STUB [=y] \textbf{[Y]}\\
+(EFI-Übergabeprotokoll (VERALTET))\\
+Wählen Sie dies, um Unterstützung für das veraltete EFI-Handover-Protokoll zu erhalten, das alternative
+Einstiegspunkte in den EFI-Stub definiert. Dies ist eine Praxis, die keine Grundlage in der UEFI-Spezifikation
+hat und ein Vorwissen seitens des Bootloaders über Linux/x86-spezifische Wege der Übergabe der Kommandozeile
+und initrd erfordert, und wo im Speicher diese Assets geladen werden können.\\
+Im Zweifelsfall sagen Sie Y. Auch wenn die entsprechende Unterstützung im Upstream-GRUB oder anderen
+Bootloadern nicht vorhanden ist, bauen die meisten Distros GRUB mit zahlreichen Downstream-Patches und können
+sich daher auf das Handover-Protokoll verlassen.
+
+\subparagraph{EFI mixed-mode support}$~$\\
+CONFIG\_EFI\_MIXED [=y] \textbf{[Y]}\\
+Wenn Sie diese Funktion aktivieren, kann ein 64-Bit-Kernel auf einer 32-Bit-Firmware gebootet werden,
+vorausgesetzt, Ihre CPU unterstützt den 64-Bit-Modus.\\
+Beachten Sie, dass es nicht möglich ist, einen Mixed-Mode-fähigen Kernel über den EFI-Boot-Stub zu
+booten -- es muss ein Bootloader verwendet werden, der das EFI-Handover-Protokoll unterstützt.\\
+Wenn Sie unsicher sind, sagen Sie N.
+
+\paragraph{Enable EFI fake memory map}$~$\\
+CONFIG\_EFI\_FAKE\_MEMMAP [=n] \textbf{[N]}\\
+Wenn Sie hier Y angeben, wird die Boot-Option \texttt{efi\_fake\_mem} aktiviert.
+Durch Angabe dieses Parameters können Sie einem bestimmten Speicherbereich beliebige Attribute hinzufügen,
+indem Sie die ursprüngliche (von der Firmware bereitgestellte) EFI-Memmap aktualisieren.
+Dies ist nützlich für das Debugging von EFI-Memmap-bezogenen Funktionen, z.B. Address Range Mirroring.
+
+\subsubsection{Timer frequency () \texorpdfstring{$\rightarrow$}{->}}
+Ermöglicht die Konfiguration der Timer-Frequenz. Es ist üblich, den Timer-Interrupt mit 1000 Hz laufen
+zu lassen, aber 100 Hz kann für Server und NUMA-Systeme vorteilhafter sein, die keine schnelle Reaktion
+für die Benutzerinteraktion benötigen und bei denen es zu Buskonflikten und Cacheline-Bounches als Folge
+von Timer-Interrupts kommen kann. Beachten Sie, dass der Timer-Interrupt in einer SMP-Umgebung auf jedem
+Prozessor auftritt, was zu NR\_CPUS * HZ Anzahl der Timer-Interrupts pro Sekunde führt.
+
+\paragraph{100~Hz}$~$\\
+CONFIG\_HZ\_100 [=n] \textbf{[N]}\\
+100~Hz ist eine typische Wahl für Server, SMP- und NUMA-Systeme mit vielen Prozessoren, die eine
+geringere Leistung aufweisen können, wenn zu viele Timer-Interrupts auftreten.
+\paragraph{250~Hz}$~$\\
+CONFIG\_HZ\_250 [=n] \textbf{[N]}\\
+250~Hz ist ein guter Kompromiss, der eine gute Serverleistung ermöglicht und auch auf SMP- und
+NUMA-Systemen eine gute interaktive Reaktionsfähigkeit zeigt. Wenn Sie NTSC-Video oder Multimedia
+verwenden, wählen Sie stattdessen 300~Hz.
+\paragraph{300~Hz}$~$\\
+CONFIG\_HZ\_300 [=y] \textbf{[Y]}\\
+300~Hz ist ein guter Kompromiss, der eine gute Serverleistung und gleichzeitig eine gute interaktive
+Reaktionsfähigkeit selbst auf SMP- und NUMA-Systemen ermöglicht und sowohl bei PAL- als auch bei
+NTSC-Bildraten für Video- und Multimedia-Arbeiten genau eingehalten wird.
+\paragraph{1000~Hz}$~$\\
+CONFIG\_HZ\_1000 [=n] \textbf{[N]}\\
+1000~Hz ist die bevorzugte Wahl für Desktop-Systeme und andere Systeme, die schnelle interaktive
+Reaktionen auf Ereignisse erfordern.
+
 \end{document}