search for: cpu_has_amd_erratum

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

...‘amd_erratum_400’ was here arch/x86/kernel/cpu/amd.c:677:1: error: extern declaration of ‘amd_erratum_383’ follows declaration with no linkage arch/x86/kernel/cpu/amd.c:675:11: note: previous definition of ‘amd_erratum_383’ was here arch/x86/kernel/cpu/amd.c:721:1: error: non-static declaration of ‘cpu_has_amd_erratum’ follows static declaration arch/x86/kernel/cpu/amd.c:679:6: note: previous definition of ‘cpu_has_amd_erratum’ was here arch/x86/kernel/cpu/amd.c:721:1: error: expected declaration or statement at end of input arch/x86/kernel/cpu/amd.c: At top level: arch/x86/kernel/cpu/amd.c:446:23: warning: ‘ini...

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection of Jailhouse via device tree hypervisor node - function-level PCI scan if Jailhouse is detected -