search for: _cr8

On 15.07.19 15:00, Andrew Cooper wrote: > There is a lot of infrastructure for functionality which is used > exclusively in __{save,restore}_processor_state() on the suspend/resume > 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? Juergen

...> > > > 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.

...s 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

...Task Priorities between CR8 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.

...erating 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...

...> > > > 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.

...nclude/asm/paravirt.h index c25c38a05c1c..0e4a0539c353 100644 --- a/arch/x86/include/asm/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/inc...

...nclude/asm/paravirt.h index c25c38a05c1c..0e4a0539c353 100644 --- a/arch/x86/include/asm/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/inc...

...PIC?): > > "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...

...PIC?): > > "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...

...nclude/asm/paravirt.h index c25c38a05c1c..0e4a0539c353 100644 --- a/arch/x86/include/asm/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/inc...

...nclude/asm/paravirt.h index c25c38a05c1c..0e4a0539c353 100644 --- a/arch/x86/include/asm/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/inc...