search for: write_cr8

...paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -139,18 +139,6 @@ static inline void __write_cr4(unsigned long x) PVOP_VCALL1(cpu.write_cr4, x); } -#ifdef CONFIG_X86_64 -static inline unsigned long read_cr8(void) -{ - return PVOP_CALL0(unsigned long, cpu.read_cr8); -} - -static inline void write_cr8(unsigned long x) -{ - PVOP_VCALL1(cpu.write_cr8, x); -} -#endif - static inline void arch_safe_halt(void) { PVOP_VCALL0(irq.safe_halt); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 946f8f1f1efc..3c775fb5524b 100644 --- a/arch/x86/include/asm/p...

...paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -139,18 +139,6 @@ static inline void __write_cr4(unsigned long x) PVOP_VCALL1(cpu.write_cr4, x); } -#ifdef CONFIG_X86_64 -static inline unsigned long read_cr8(void) -{ - return PVOP_CALL0(unsigned long, cpu.read_cr8); -} - -static inline void write_cr8(unsigned long x) -{ - PVOP_VCALL1(cpu.write_cr8, x); -} -#endif - static inline void arch_safe_halt(void) { PVOP_VCALL0(irq.safe_halt); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 946f8f1f1efc..3c775fb5524b 100644 --- a/arch/x86/include/asm/p...

...paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -139,18 +139,6 @@ static inline void __write_cr4(unsigned long x) PVOP_VCALL1(cpu.write_cr4, x); } -#ifdef CONFIG_X86_64 -static inline unsigned long read_cr8(void) -{ - return PVOP_CALL0(unsigned long, cpu.read_cr8); -} - -static inline void write_cr8(unsigned long x) -{ - PVOP_VCALL1(cpu.write_cr8, x); -} -#endif - static inline void arch_safe_halt(void) { PVOP_VCALL0(irq.safe_halt); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 946f8f1f1efc..3c775fb5524b 100644 --- a/arch/x86/include/asm/p...

...paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -139,18 +139,6 @@ static inline void __write_cr4(unsigned long x) PVOP_VCALL1(cpu.write_cr4, x); } -#ifdef CONFIG_X86_64 -static inline unsigned long read_cr8(void) -{ - return PVOP_CALL0(unsigned long, cpu.read_cr8); -} - -static inline void write_cr8(unsigned long x) -{ - PVOP_VCALL1(cpu.write_cr8, x); -} -#endif - static inline void arch_safe_halt(void) { PVOP_VCALL0(irq.safe_halt); diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h index 946f8f1f1efc..3c775fb5524b 100644 --- a/arch/x86/include/asm/p...

...and APIC?): > > "Operating software should implement either direct APIC TPR updates or CR8 > style TPR updates but not mix them. Software can use a serializing > instruction (for example, CPUID) to serialize updates between MOV CR8 and > stores to the APIC.? > > And native_write_cr8() did not even issue a serializing instruction. > Given its location, the one write_cr8() is bounded by two serialising operations, so is safe in practice. However, I agree with the statement in the manual.? I could submit a v3 with an updated commit message, or let it be fixed on commit.? Whi...

...and APIC?): > > "Operating software should implement either direct APIC TPR updates or CR8 > style TPR updates but not mix them. Software can use a serializing > instruction (for example, CPUID) to serialize updates between MOV CR8 and > stores to the APIC.? > > And native_write_cr8() did not even issue a serializing instruction. > Given its location, the one write_cr8() is bounded by two serialising operations, so is safe in practice. However, I agree with the statement in the manual.? I could submit a v3 with an updated commit message, or let it be fixed on commit.? Whi...

...path. > > > > cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored > > independently by lapic_{suspend,resume}(). > > Aren't those called only with CONFIG_PM set? > Unless I'm missing something, we only build any of the restore code (including the write_cr8() call) if CONFIG_PM_SLEEP is set, and that selects CONFIG_PM, so we should be fine, I think.

...path. > > > > cr8 is an alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored > > independently by lapic_{suspend,resume}(). > > Aren't those called only with CONFIG_PM set? > Unless I'm missing something, we only build any of the restore code (including the write_cr8() call) if CONFIG_PM_SLEEP is set, and that selects CONFIG_PM, so we should be fine, I think.

...ot;Operating software should implement either direct APIC TPR updates or CR8 > > style TPR updates but not mix them. Software can use a serializing > > instruction (for example, CPUID) to serialize updates between MOV CR8 and > > stores to the APIC.? > > > > And native_write_cr8() did not even issue a serializing instruction. > > > > Given its location, the one write_cr8() is bounded by two serialising > operations, so is safe in practice. > > However, I agree with the statement in the manual. I could submit a v3 > with an updated commit message, o...

...nsigned long read_cr8(void) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 19a3e8f961c7..3fead3a50723 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -332,7 +332,6 @@ __visible struct pv_cpu_ops pv_cpu_ops = { .read_cr8 = native_read_cr8, .write_cr8 = native_write_cr8, #endif - .wbinvd = native_wbinvd, .read_msr = native_read_msr, .write_msr = native_write_msr, .read_msr_safe = native_read_msr_safe, diff --git a/arch/x86/kernel/paravirt_patch_64.c b/arch/x86/kernel/paravirt_patch_64.c index 11aaf1eaa0e4..0a1ba3f80cbf 100644 --- a/arch/x...

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

The long term plan has been to replace Xen PV guests by PVH. The first victim of that plan are now 32-bit PV guests, as those are used only rather seldom these days. Xen on x86 requires 64-bit support and with Grub2 now supporting PVH officially since version 2.04 there is no need to keep 32-bit PV guest support alive in the Linux kernel. Additionally Meltdown mitigation is not available in the

...alias of APIC_TASKPRI, and APIC_TASKPRI is saved/restored >>> independently by lapic_{suspend,resume}(). >> >> Aren't those called only with CONFIG_PM set? >> > > > Unless I'm missing something, we only build any of the restore code > (including the write_cr8() call) if CONFIG_PM_SLEEP is set, and that > selects CONFIG_PM, so we should be fine, I think. > Okay, in that case I'd suggest to remove "cr8" from struct saved_context as it won't be used any longer. Juergen

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

This series removes some no longer needed stuff from paravirt infrastructure and puts large quantities of paravirt ops under a new config option PARAVIRT_XXL which is selected by XEN_PV only. A pvops kernel without XEN_PV being configured is about 2.5% smaller with this series applied. tip commit 5800dc5c19f34e6e03b5adab1282535cb102fafd ("x86/paravirt: Fix spectre-v2 mitigations for

...-__visible struct pv_cpu_ops pv_cpu_ops = { - .cpuid = native_cpuid, - .get_debugreg = native_get_debugreg, - .set_debugreg = native_set_debugreg, - .read_cr0 = native_read_cr0, - .write_cr0 = native_write_cr0, - .write_cr4 = native_write_cr4, -#ifdef CONFIG_X86_64 - .read_cr8 = native_read_cr8, - .write_cr8 = native_write_cr8, -#endif - .wbinvd = native_wbinvd, - .read_msr = native_read_msr, - .write_msr = native_write_msr, - .read_msr_safe = native_read_msr_safe, - .write_msr_safe = native_write_msr_safe, - .read_pmc = native_read_pmc, - .load_tr_desc = native_load_tr_desc, - .set_ldt = native_set_ld...

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Today paravirtualization is a all-or-nothing game: either a kernel is compiled with no paravirtualization support at all, or it is supporting paravirtualized environments like Xen pv-guests or lguest additionally to some paravirtualized tuning for KVM, Hyperv, VMWare or Xen HVM-guests. As support of pv-guests requires quite intrusive pv-hooks (e.g. all access functions to page table entries,

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This