search for: irets

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

I'm implementing a more efficient version of the Xen iret paravirt_op, so that it can use the real iret instruction where possible. I really need to get access to per-cpu variables, so I can set the event mask state in the vcpu_info structure, but unfortunately at the point where INTERRUPT_RETURN is used in entry.S, the usermode %fs has already been restored. How would you feel if we changed

i386 Transparent paravirtualization patch #1. Add support for interrupt holdoff to the entry.S fault and syscall paths. This is a straightforward macro-ization for the default sub-architecture. Note that CLI, STI and IRET may be called with non-flat segments because guest %ds and %es segments are live at the time. Any alternative implementation (such as a virtual interrupt mask) is required to

i386 Transparent paravirtualization patch #1. Add support for interrupt holdoff to the entry.S fault and syscall paths. This is a straightforward macro-ization for the default sub-architecture. Note that CLI, STI and IRET may be called with non-flat segments because guest %ds and %es segments are live at the time. Any alternative implementation (such as a virtual interrupt mask) is required to

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

On Fri, Aug 07, 2020 at 10:38:23AM +0200, Juergen Gross wrote: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2,

Hi all. I post a small app I made that create 2 clips using a V4L device. I would like to get every tips you think it's useful... Some notes: - I make 2 clips because in our project we create series of clips and it's important to check that the all the resources ( memory, descriptors, etc. ) are freed correctly and to reuse all the resources that can be reused - the clips are not well

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

xen: use iret directly where possible Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically with re-enabling

xen: use iret directly where possible Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically with re-enabling

xen: use iret directly where possible Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically with re-enabling

[ Expand, correct and clarify comments; minor code change. ] Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically

[ Expand, correct and clarify comments; minor code change. ] Most of the time we can simply use the iret instruction to exit the kernel, rather than having to use the iret hypercall - the only exception is if we're returning into vm86 mode, or from delivering an NMI (which we don't support yet). When running native, iret has the behaviour of testing for a pending interrupt atomically

Illustration of how VMI inlines are used to greatly limit the impact of code change in low level assembler code. Spinlocks, system calls, and the fault handling paths are affected by adding some padding bytes to convert the native instructions into a hook point for the hypervisor to insert shim code. These changes are sufficient to glue the Linux low level entry points to hypervisor event

Illustration of how VMI inlines are used to greatly limit the impact of code change in low level assembler code. Spinlocks, system calls, and the fault handling paths are affected by adding some padding bytes to convert the native instructions into a hook point for the hypervisor to insert shim code. These changes are sufficient to glue the Linux low level entry points to hypervisor event

From: Boris Ostrovsky <boris.ostrovsky at oracle.com> commit 88c15ec90ff16880efab92b519436ee17b198477 upstream. As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests", the irq_enable_sysexit pv op is not called by Xen PV guests anymore and since they were the only ones who used it we can safely remove it. Signed-off-by: Boris Ostrovsky <boris.ostrovsky at

Xen PV guests have been the only ones using it and now they don't. Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> --- arch/x86/entry/entry_32.S | 8 ++------ arch/x86/include/asm/paravirt.h | 7 ------- arch/x86/include/asm/paravirt_types.h | 9 --------- arch/x86/kernel/asm-offsets.c | 3 --- arch/x86/kernel/paravirt.c | 7

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

This is a note to let you know that I've just added the patch titled x86/paravirt: Remove the unused irq_enable_sysexit pv op to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-paravirt-remove-the-unused-irq_enable_sysexit-pv-op.patch and it can be found in the queue-4.4