search for: native_

...; > Tracing, we also musn't call into tracing when using raw_local_irq_*(). > Because then we re-intoduce this same issue all over again. > > Both halt() and safe_halt() are more paravirt calls, but given we're in > a KVM paravirt call already, I suppose we can directly use native_*() > here. > > Something like so then... I suppose, but then the Xen variants need TLC > too. Just to be sure I understand you correct: You mean that xen_qlock_kick() and xen_qlock_wait() and all functions called by those should gain the "notrace" attribute, right? I am no...

...; > Tracing, we also musn't call into tracing when using raw_local_irq_*(). > Because then we re-intoduce this same issue all over again. > > Both halt() and safe_halt() are more paravirt calls, but given we're in > a KVM paravirt call already, I suppose we can directly use native_*() > here. > > Something like so then... I suppose, but then the Xen variants need TLC > too. Just to be sure I understand you correct: You mean that xen_qlock_kick() and xen_qlock_wait() and all functions called by those should gain the "notrace" attribute, right? I am no...

On 04/10/17 17:58, Josh Poimboeuf wrote: > In a future patch, the NATIVE_* instruction string macros will be used > in GCC extended inline asm, which requires registers to have two '%' > instead of one in the asm template string. Convert the DEF_NATIVE macro > to the GCC extended asm syntax so the NATIVE_* macros can be shared more > broadly. > &...

In a future patch, the NATIVE_* instruction string macros will be used in GCC extended inline asm, which requires registers to have two '%' instead of one in the asm template string. Convert the DEF_NATIVE macro to the GCC extended asm syntax so the NATIVE_* macros can be shared more broadly. Signed-off-by: Josh Poimbo...

On Tue, Apr 28, 2020 at 05:16:50PM +0200, Joerg Roedel wrote: > +static inline u64 sev_es_rd_ghcb_msr(void) > +{ > + return native_read_msr(MSR_AMD64_SEV_ES_GHCB); > +} > + > +static inline void sev_es_wr_ghcb_msr(u64 val) > +{ > + u32 low, high; > + > + low = (u32)(val); > + high = (u32)(val >> 32); > + > + native_write_msr(MSR_AMD64_SEV_ES_GHCB, low, high); > +} Instead of duplicating...

On Tue, Apr 28, 2020 at 05:16:50PM +0200, Joerg Roedel wrote: > +static inline u64 sev_es_rd_ghcb_msr(void) > +{ > + return native_read_msr(MSR_AMD64_SEV_ES_GHCB); > +} > + > +static inline void sev_es_wr_ghcb_msr(u64 val) > +{ > + u32 low, high; > + > + low = (u32)(val); > + high = (u32)(val >> 32); > + > + native_write_msr(MSR_AMD64_SEV_ES_GHCB, low, high); > +} Instead of duplicating...

On Wed, May 20, 2020 at 11:14:15AM +0200, Borislav Petkov wrote: > On Tue, Apr 28, 2020 at 05:16:50PM +0200, Joerg Roedel wrote: > > +static inline u64 sev_es_rd_ghcb_msr(void) > > +{ > > + return native_read_msr(MSR_AMD64_SEV_ES_GHCB); > > +} > > + > > +static inline void sev_es_wr_ghcb_msr(u64 val) > > +{ > > + u32 low, high; > > + > > + low = (u32)(val); > > + high = (u32)(val >> 32); > > + > > + native_write_msr(MSR_AMD64_SEV_ES_...

...also musn't call into tracing when using raw_local_irq_*(). > > Because then we re-intoduce this same issue all over again. > > > > Both halt() and safe_halt() are more paravirt calls, but given we're in > > a KVM paravirt call already, I suppose we can directly use native_*() > > here. > > > > Something like so then... I suppose, but then the Xen variants need TLC > > too. > > Just to be sure I understand you correct: > > You mean that xen_qlock_kick() and xen_qlock_wait() and all functions > called by those should gain the &...

...39;t call into tracing when using raw_local_irq_*(). >>> Because then we re-intoduce this same issue all over again. >>> >>> Both halt() and safe_halt() are more paravirt calls, but given we're in >>> a KVM paravirt call already, I suppose we can directly use native_*() >>> here. >>> >>> Something like so then... I suppose, but then the Xen variants need TLC >>> too. >> >> Just to be sure I understand you correct: >> >> You mean that xen_qlock_kick() and xen_qlock_wait() and all functions >> call...

...39;t call into tracing when using raw_local_irq_*(). >>> Because then we re-intoduce this same issue all over again. >>> >>> Both halt() and safe_halt() are more paravirt calls, but given we're in >>> a KVM paravirt call already, I suppose we can directly use native_*() >>> here. >>> >>> Something like so then... I suppose, but then the Xen variants need TLC >>> too. >> >> Just to be sure I understand you correct: >> >> You mean that xen_qlock_kick() and xen_qlock_wait() and all functions >> call...

...is is definitely an issue. Tracing, we also musn't call into tracing when using raw_local_irq_*(). Because then we re-intoduce this same issue all over again. Both halt() and safe_halt() are more paravirt calls, but given we're in a KVM paravirt call already, I suppose we can directly use native_*() here. Something like so then... I suppose, but then the Xen variants need TLC too. --- arch/x86/include/asm/irqflags.h | 4 ++-- arch/x86/include/asm/kvm_para.h | 18 +++++++++--------- arch/x86/kernel/kvm.c | 14 +++++++------- 3 files changed, 18 insertions(+), 18 deletions(-) d...

If we're building a pte, we can use simple assigment; only use set_pte etc. when we're actually going to use that destination as a PTE. I don't know that we'll ever run under Xen, but it's neater. And use set_pte/set_pmd rather than assuming native_ versions, even though that's probably true for most people. (Includes compile fix by Kamalesh Babulal <kamalesh at linux.vnet.ibm.com>) Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Matias Zabaljauregui <zabaljauregui at gmail.com> Cc: Kamalesh Babulal <kamal...

If we're building a pte, we can use simple assigment; only use set_pte etc. when we're actually going to use that destination as a PTE. I don't know that we'll ever run under Xen, but it's neater. And use set_pte/set_pmd rather than assuming native_ versions, even though that's probably true for most people. (Includes compile fix by Kamalesh Babulal <kamalesh at linux.vnet.ibm.com>) Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Matias Zabaljauregui <zabaljauregui at gmail.com> Cc: Kamalesh Babulal <kamal...

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote: > On Wed, Aug 05, 2020 at 03:42PM +0200, peterz at infradead.org wrote: > > Shouldn't we __always_inline those? They're going to be really small. > > I can send a v2, and you can choose. For reference, though: > > ffffffff86271ee0 <arch_local_save_flags>: > ffffffff86271ee0: 0f 1f 44 00 00

Hey folks, This is the part-of-pvops-implementation-that-is-not-exactly-a-merge. Neat, uh? This is the majority of the work. The first patch in the series does not really belong here. It was already sent to lkml separetedly before, but I'm including it again, for a very simple reason: Try to test the paravirt patches without it, and you'll fail miserably ;-) (and it was not yet

Hey folks, This is the part-of-pvops-implementation-that-is-not-exactly-a-merge. Neat, uh? This is the majority of the work. The first patch in the series does not really belong here. It was already sent to lkml separetedly before, but I'm including it again, for a very simple reason: Try to test the paravirt patches without it, and you'll fail miserably ;-) (and it was not yet

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases