From: Boris Ostrovsky <boris.ostrovsky@oracle.com> To: Andrew Cooper <andrew.cooper3@citrix.com>, Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com>, Rusty Russell <rusty@rustcorp.com.au>, Mike Galbraith <efault@gmx.de>, xen-devel@lists.xenproject.org, Peter Zijlstra <peterz@infradead.org>, Jiri Slaby <jslaby@suse.cz>, x86@kernel.org, linux-kernel@vger.kernel.org, Sasha Levin <alexander.levin@verizon.com>, Chris Wright <chrisw@sous-sol.org>, Thomas Gleixner <tglx@linutronix.de>, Andy Lutomirski <luto@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>, live-patching@vger.kernel.org, Alok Kataria <akataria@vmware.com>, virtualization@lists.linux-foundation.org, Linus Torvalds <torvalds@linux-foundation.org>, Ingo Molnar <mingo@kernel.org> Subject: Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure Date: Thu, 12 Oct 2017 15:53:28 -0400 [thread overview] Message-ID: <a6c3be0b-35f4-8d23-4ea2-ead94a3fc69e@oracle.com> (raw) In-Reply-To: <ed30216f-4b9e-2bc3-b1d2-36135b29d746@citrix.com> On 10/12/2017 03:27 PM, Andrew Cooper wrote: > On 12/10/17 20:11, Boris Ostrovsky wrote: >> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>>>> #ifdef CONFIG_PARAVIRT >>>>> +/* >>>>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>>>> + * They are only applied when running on a hypervisor. They replace some >>>>> + * native instructions with calls to pv ops. >>>>> + */ >>>>> +void __init apply_pv_alternatives(void) >>>>> +{ >>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS); >>>> Not for Xen HVM guests. >>> From what I can tell, HVM guests still use pv_time_ops and >>> pv_mmu_ops.exit_mmap, right? >>> >>>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); >>>>> +} >>>> This is a problem (at least for Xen PV guests): >>>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. >>> Ah, right. >>> >>>> It might be possible not to turn off/on the interrupts in this >>>> particular case since the guest probably won't be able to handle an >>>> interrupt at this point anyway. >>> Yeah, that should work. For Xen and for the other hypervisors, this is >>> called well before irq init, so interrupts can't be handled yet anyway. >> There is also another problem: >> >> [ 1.312425] general protection fault: 0000 [#1] SMP >> [ 1.312901] Modules linked in: >> [ 1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 >> [ 1.313878] task: ffff88003e2c0000 task.stack: ffffc9000038c000 >> [ 1.314360] RIP: 10000e030:entry_SYSCALL_64_fastpath+0x1/0xa5 >> [ 1.314854] RSP: e02b:ffffc9000038ff50 EFLAGS: 00010046 >> [ 1.315336] RAX: 000000000000000c RBX: 000055f550168040 RCX: >> 00007fcfc959f59a >> [ 1.315827] RDX: 0000000000000000 RSI: 0000000000000000 RDI: >> 0000000000000000 >> [ 1.316315] RBP: 000000000000000a R08: 000000000000037f R09: >> 0000000000000064 >> [ 1.316805] R10: 000000001f89cbf5 R11: ffff88003e2c0000 R12: >> 00007fcfc958ad60 >> [ 1.317300] R13: 0000000000000000 R14: 000055f550185954 R15: >> 0000000000001000 >> [ 1.317801] FS: 0000000000000000(0000) GS:ffff88003f800000(0000) >> knlGS:0000000000000000 >> [ 1.318267] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 1.318750] CR2: 00007fcfc97ab218 CR3: 000000003c88e000 CR4: >> 0000000000042660 >> [ 1.319235] Call Trace: >> [ 1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 >> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 >> 00 50 <ff> 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 >> [ 1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: ffffc9000038ff50 >> [ 1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- >> [ 1.345009] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x0000000b >> >> >> All code >> ======== >> 0: 51 push %rcx >> 1: 50 push %rax >> 2: 57 push %rdi >> 3: 56 push %rsi >> 4: 52 push %rdx >> 5: 51 push %rcx >> 6: 6a da pushq $0xffffffffffffffda >> 8: 41 50 push %r8 >> a: 41 51 push %r9 >> c: 41 52 push %r10 >> e: 41 53 push %r11 >> 10: 48 83 ec 30 sub $0x30,%rsp >> 14: 65 4c 8b 1c 25 c0 d2 mov %gs:0xd2c0,%r11 >> 1b: 00 00 >> 1d: 41 f7 03 df 39 08 90 testl $0x900839df,(%r11) >> 24: 0f 85 a5 00 00 00 jne 0xcf >> 2a: 50 push %rax >> 2b:* ff 15 9c 95 d0 ff callq *-0x2f6a64(%rip) # >> 0xffffffffffd095cd <-- trapping instruction >> 31: 58 pop %rax >> 32: 48 3d 4c 01 00 00 cmp $0x14c,%rax >> 38: 77 0f ja 0x49 >> 3a: 4c 89 d1 mov %r10,%rcx >> 3d: ff .byte 0xff >> 3e: 14 c5 adc $0xc5,%al >> >> >> so the original 'cli' was replaced with the pv call but to me the offset >> looks a bit off, no? Shouldn't it always be positive? > callq takes a 32bit signed displacement, so jumping back by up to 2G is > perfectly legitimate. Yes, but ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath ffffffff817365dd t entry_SYSCALL_64_fastpath ostr@workbase> nm vmlinux | grep " pv_irq_ops" ffffffff81c2dbc0 D pv_irq_ops ostr@workbase> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I didn't mean that x86 instruction set doesn't allow negative displacement, I was trying to say that pv_irq_ops always live further down) > > The #GP[0] however means that whatever 8 byte value was found at > -0x2f6a64(%rip) was a non-canonical address. > > One option is that the pvops structure hasn't been initialised properly, It was, I did check that. And just to make sure I re-initialized it before alt instructions were rewritten. > but an alternative is that the relocation wasn't processed correctly, > and the code is trying to reference something which isn't a function > pointer. Let me see if I can poke at what's there. -boris
WARNING: multiple messages have this Message-ID (diff)
From: Boris Ostrovsky <boris.ostrovsky@oracle.com> To: Andrew Cooper <andrew.cooper3@citrix.com>, Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com>, Mike Galbraith <efault@gmx.de>, Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linux-foundation.org>, Rusty Russell <rusty@rustcorp.com.au>, virtualization@lists.linux-foundation.org, x86@kernel.org, linux-kernel@vger.kernel.org, Chris Wright <chrisw@sous-sol.org>, live-patching@vger.kernel.org, Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, xen-devel@lists.xenproject.org, Thomas Gleixner <tglx@linutronix.de>, Sasha Levin <alexander.levin@verizon.com>, Jiri Slaby <jslaby@suse.cz>, Alok Kataria <akataria@vmware.com> Subject: Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure Date: Thu, 12 Oct 2017 15:53:28 -0400 [thread overview] Message-ID: <a6c3be0b-35f4-8d23-4ea2-ead94a3fc69e@oracle.com> (raw) In-Reply-To: <ed30216f-4b9e-2bc3-b1d2-36135b29d746@citrix.com> On 10/12/2017 03:27 PM, Andrew Cooper wrote: > On 12/10/17 20:11, Boris Ostrovsky wrote: >> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote: >>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote: >>>>> #ifdef CONFIG_PARAVIRT >>>>> +/* >>>>> + * Paravirt alternatives are applied much earlier than normal alternatives. >>>>> + * They are only applied when running on a hypervisor. They replace some >>>>> + * native instructions with calls to pv ops. >>>>> + */ >>>>> +void __init apply_pv_alternatives(void) >>>>> +{ >>>>> + setup_force_cpu_cap(X86_FEATURE_PV_OPS); >>>> Not for Xen HVM guests. >>> From what I can tell, HVM guests still use pv_time_ops and >>> pv_mmu_ops.exit_mmap, right? >>> >>>>> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end); >>>>> +} >>>> This is a problem (at least for Xen PV guests): >>>> apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death. >>> Ah, right. >>> >>>> It might be possible not to turn off/on the interrupts in this >>>> particular case since the guest probably won't be able to handle an >>>> interrupt at this point anyway. >>> Yeah, that should work. For Xen and for the other hypervisors, this is >>> called well before irq init, so interrupts can't be handled yet anyway. >> There is also another problem: >> >> [ 1.312425] general protection fault: 0000 [#1] SMP >> [ 1.312901] Modules linked in: >> [ 1.313389] CPU: 0 PID: 1 Comm: init Not tainted 4.14.0-rc4+ #6 >> [ 1.313878] task: ffff88003e2c0000 task.stack: ffffc9000038c000 >> [ 1.314360] RIP: 10000e030:entry_SYSCALL_64_fastpath+0x1/0xa5 >> [ 1.314854] RSP: e02b:ffffc9000038ff50 EFLAGS: 00010046 >> [ 1.315336] RAX: 000000000000000c RBX: 000055f550168040 RCX: >> 00007fcfc959f59a >> [ 1.315827] RDX: 0000000000000000 RSI: 0000000000000000 RDI: >> 0000000000000000 >> [ 1.316315] RBP: 000000000000000a R08: 000000000000037f R09: >> 0000000000000064 >> [ 1.316805] R10: 000000001f89cbf5 R11: ffff88003e2c0000 R12: >> 00007fcfc958ad60 >> [ 1.317300] R13: 0000000000000000 R14: 000055f550185954 R15: >> 0000000000001000 >> [ 1.317801] FS: 0000000000000000(0000) GS:ffff88003f800000(0000) >> knlGS:0000000000000000 >> [ 1.318267] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 1.318750] CR2: 00007fcfc97ab218 CR3: 000000003c88e000 CR4: >> 0000000000042660 >> [ 1.319235] Call Trace: >> [ 1.319700] Code: 51 50 57 56 52 51 6a da 41 50 41 51 41 52 41 53 48 >> 83 ec 30 65 4c 8b 1c 25 c0 d2 00 00 41 f7 03 df 39 08 90 0f 85 a5 00 00 >> 00 50 <ff> 15 9c 95 d0 ff 58 48 3d 4c 01 00 00 77 0f 4c 89 d1 ff 14 c5 >> [ 1.321161] RIP: entry_SYSCALL_64_fastpath+0x1/0xa5 RSP: ffffc9000038ff50 >> [ 1.344255] ---[ end trace d7cb8cd6cd7c294c ]--- >> [ 1.345009] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x0000000b >> >> >> All code >> ======== >> 0: 51 push %rcx >> 1: 50 push %rax >> 2: 57 push %rdi >> 3: 56 push %rsi >> 4: 52 push %rdx >> 5: 51 push %rcx >> 6: 6a da pushq $0xffffffffffffffda >> 8: 41 50 push %r8 >> a: 41 51 push %r9 >> c: 41 52 push %r10 >> e: 41 53 push %r11 >> 10: 48 83 ec 30 sub $0x30,%rsp >> 14: 65 4c 8b 1c 25 c0 d2 mov %gs:0xd2c0,%r11 >> 1b: 00 00 >> 1d: 41 f7 03 df 39 08 90 testl $0x900839df,(%r11) >> 24: 0f 85 a5 00 00 00 jne 0xcf >> 2a: 50 push %rax >> 2b:* ff 15 9c 95 d0 ff callq *-0x2f6a64(%rip) # >> 0xffffffffffd095cd <-- trapping instruction >> 31: 58 pop %rax >> 32: 48 3d 4c 01 00 00 cmp $0x14c,%rax >> 38: 77 0f ja 0x49 >> 3a: 4c 89 d1 mov %r10,%rcx >> 3d: ff .byte 0xff >> 3e: 14 c5 adc $0xc5,%al >> >> >> so the original 'cli' was replaced with the pv call but to me the offset >> looks a bit off, no? Shouldn't it always be positive? > callq takes a 32bit signed displacement, so jumping back by up to 2G is > perfectly legitimate. Yes, but ostr@workbase> nm vmlinux | grep entry_SYSCALL_64_fastpath ffffffff817365dd t entry_SYSCALL_64_fastpath ostr@workbase> nm vmlinux | grep " pv_irq_ops" ffffffff81c2dbc0 D pv_irq_ops ostr@workbase> so pv_irq_ops.irq_disable is about 5MB ahead of where we are now. (I didn't mean that x86 instruction set doesn't allow negative displacement, I was trying to say that pv_irq_ops always live further down) > > The #GP[0] however means that whatever 8 byte value was found at > -0x2f6a64(%rip) was a non-canonical address. > > One option is that the pvops structure hasn't been initialised properly, It was, I did check that. And just to make sure I re-initialized it before alt instructions were rewritten. > but an alternative is that the relocation wasn't processed correctly, > and the code is trying to reference something which isn't a function > pointer. Let me see if I can poke at what's there. -boris
next prev parent reply other threads:[~2017-10-12 19:53 UTC|newest] Thread overview: 175+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-04 15:58 [PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 01/13] x86/paravirt: remove wbinvd() paravirt interface Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-24 13:17 ` Juergen Gross 2017-10-24 13:17 ` Juergen Gross 2017-10-24 13:17 ` Juergen Gross 2017-11-17 14:39 ` Borislav Petkov 2017-11-17 14:39 ` Borislav Petkov 2017-11-17 14:39 ` Borislav Petkov 2017-10-04 15:58 ` [PATCH 02/13] x86/paravirt: Fix output constraint macro names Josh Poimboeuf 2017-10-25 9:33 ` Juergen Gross 2017-10-25 9:33 ` Juergen Gross 2017-11-16 20:50 ` Josh Poimboeuf 2017-11-16 20:50 ` Josh Poimboeuf 2017-11-16 20:50 ` Josh Poimboeuf 2017-11-17 6:55 ` Juergen Gross 2017-11-17 6:55 ` Juergen Gross 2017-11-17 6:55 ` Juergen Gross 2017-10-25 9:33 ` Juergen Gross 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 9:46 ` Juergen Gross 2017-10-25 9:46 ` Juergen Gross 2017-10-25 9:46 ` Juergen Gross 2017-11-16 21:04 ` Josh Poimboeuf 2017-11-16 21:04 ` Josh Poimboeuf 2017-11-16 21:04 ` Josh Poimboeuf 2017-11-17 18:07 ` Borislav Petkov 2017-11-17 18:07 ` Borislav Petkov 2017-11-17 18:07 ` Borislav Petkov 2017-11-17 19:10 ` Juergen Gross 2017-11-17 19:10 ` Juergen Gross 2017-11-17 19:10 ` Juergen Gross 2017-11-17 19:42 ` Josh Poimboeuf 2017-11-17 19:42 ` Josh Poimboeuf 2017-11-18 10:20 ` Juergen Gross 2017-11-18 10:20 ` Juergen Gross 2017-11-18 13:17 ` Josh Poimboeuf 2017-11-18 13:17 ` Josh Poimboeuf 2017-11-18 13:17 ` Josh Poimboeuf 2017-11-18 10:20 ` Juergen Gross 2017-11-17 19:42 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 04/13] x86/paravirt: Convert DEF_NATIVE macro to GCC extended asm syntax Josh Poimboeuf 2017-10-25 10:03 ` Juergen Gross 2017-10-25 10:03 ` Juergen Gross 2017-10-25 10:03 ` Juergen Gross 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 05/13] x86/paravirt: Move paravirt asm macros to paravirt-asm.h Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 10:32 ` Juergen Gross 2017-10-25 10:32 ` Juergen Gross 2017-10-25 10:32 ` Juergen Gross 2017-10-04 15:58 ` [PATCH 06/13] x86/paravirt: Clean up paravirt-asm.h Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 10:59 ` Juergen Gross 2017-10-25 10:59 ` Juergen Gross 2017-10-25 10:59 ` Juergen Gross 2017-10-04 15:58 ` [PATCH 07/13] x86/paravirt: Simplify ____PVOP_CALL() Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 11:01 ` Juergen Gross 2017-10-25 11:01 ` Juergen Gross 2017-10-25 11:01 ` Juergen Gross 2017-11-22 16:35 ` Borislav Petkov 2017-11-22 16:35 ` Borislav Petkov 2017-11-22 16:35 ` Borislav Petkov 2017-10-04 15:58 ` [PATCH 08/13] x86/paravirt: Clean up paravirt_types.h Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 11:08 ` Juergen Gross 2017-10-25 11:08 ` Juergen Gross 2017-10-25 11:08 ` Juergen Gross 2017-11-22 20:46 ` Borislav Petkov 2017-11-22 20:46 ` Borislav Petkov 2017-11-22 20:46 ` Borislav Petkov 2017-10-04 15:58 ` [PATCH 09/13] x86/asm: Convert ALTERNATIVE*() assembler macros to preprocessor macros Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 11:14 ` Juergen Gross 2017-10-25 11:14 ` Juergen Gross 2017-10-25 11:14 ` Juergen Gross 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 10/13] x86/alternative: Support indirect call replacement Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-25 11:25 ` Juergen Gross 2017-10-25 11:25 ` Juergen Gross 2017-10-25 11:25 ` Juergen Gross 2017-11-16 21:19 ` Josh Poimboeuf 2017-11-16 21:19 ` Josh Poimboeuf 2017-11-16 21:19 ` Josh Poimboeuf 2017-11-17 5:46 ` Juergen Gross 2017-11-17 5:46 ` Juergen Gross 2017-11-17 5:46 ` Juergen Gross 2017-11-17 19:52 ` H. Peter Anvin 2017-11-17 19:52 ` H. Peter Anvin 2017-11-17 19:52 ` H. Peter Anvin 2017-10-04 15:58 ` [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure Josh Poimboeuf 2017-10-05 20:35 ` Boris Ostrovsky 2017-10-05 20:35 ` Boris Ostrovsky 2017-10-06 14:32 ` Josh Poimboeuf 2017-10-06 15:29 ` Boris Ostrovsky 2017-10-06 15:29 ` Boris Ostrovsky 2017-10-06 16:30 ` Josh Poimboeuf 2017-10-06 16:30 ` Josh Poimboeuf 2017-10-06 16:30 ` Josh Poimboeuf 2017-10-06 15:29 ` Boris Ostrovsky 2017-10-12 19:11 ` Boris Ostrovsky 2017-10-12 19:11 ` Boris Ostrovsky 2017-10-12 19:11 ` Boris Ostrovsky 2017-10-12 19:27 ` Andrew Cooper 2017-10-12 19:27 ` [Xen-devel] " Andrew Cooper 2017-10-12 19:27 ` Andrew Cooper 2017-10-12 19:53 ` Boris Ostrovsky 2017-10-12 19:53 ` Boris Ostrovsky [this message] 2017-10-12 19:53 ` [Xen-devel] " Boris Ostrovsky 2017-10-16 18:18 ` Boris Ostrovsky 2017-10-16 18:18 ` [Xen-devel] " Boris Ostrovsky 2017-10-16 18:18 ` Boris Ostrovsky 2017-10-17 5:24 ` Josh Poimboeuf 2017-10-17 5:24 ` Josh Poimboeuf 2017-10-17 13:58 ` Boris Ostrovsky 2017-10-17 13:58 ` Boris Ostrovsky 2017-10-17 14:36 ` Josh Poimboeuf 2017-10-17 14:36 ` [Xen-devel] " Josh Poimboeuf 2017-10-17 14:36 ` Josh Poimboeuf 2017-10-17 15:36 ` Boris Ostrovsky 2017-10-17 15:36 ` [Xen-devel] " Boris Ostrovsky 2017-10-17 15:36 ` Boris Ostrovsky 2017-10-17 20:17 ` Josh Poimboeuf 2017-10-17 20:17 ` Josh Poimboeuf 2017-10-17 20:36 ` Boris Ostrovsky 2017-10-17 20:36 ` Boris Ostrovsky 2017-10-17 20:50 ` Josh Poimboeuf 2017-10-17 20:50 ` [Xen-devel] " Josh Poimboeuf 2017-10-17 20:59 ` Boris Ostrovsky 2017-10-17 20:59 ` Boris Ostrovsky 2017-10-17 21:03 ` Josh Poimboeuf 2017-10-17 21:03 ` [Xen-devel] " Josh Poimboeuf 2017-10-17 21:03 ` Josh Poimboeuf 2017-10-17 20:59 ` Boris Ostrovsky 2017-10-17 20:50 ` [Xen-devel] " Josh Poimboeuf 2017-10-17 20:36 ` Boris Ostrovsky 2017-10-17 20:17 ` Josh Poimboeuf 2017-10-17 13:58 ` Boris Ostrovsky 2017-10-17 5:24 ` Josh Poimboeuf 2017-10-17 13:10 ` [Xen-devel] " Brian Gerst 2017-10-17 13:10 ` Brian Gerst 2017-10-17 13:10 ` [Xen-devel] " Brian Gerst 2017-10-17 14:05 ` Boris Ostrovsky 2017-10-17 14:05 ` [Xen-devel] " Boris Ostrovsky 2017-10-17 14:05 ` Boris Ostrovsky 2017-10-06 14:32 ` Josh Poimboeuf 2017-10-06 14:32 ` Josh Poimboeuf 2017-10-05 20:35 ` Boris Ostrovsky 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 12/13] objtool: Add support for new .pv_altinstructions section Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` [PATCH 13/13] x86/paravirt: Convert natively patched pv ops to use paravirt alternatives Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-04 15:58 ` Josh Poimboeuf 2017-10-06 7:35 ` [Xen-devel] [PATCH 00/13] x86/paravirt: Make pv ops code generation more closely match reality Vitaly Kuznetsov 2017-10-06 7:35 ` Vitaly Kuznetsov 2017-10-06 14:36 ` Josh Poimboeuf 2017-10-06 14:36 ` Josh Poimboeuf 2017-10-06 14:36 ` [Xen-devel] " Josh Poimboeuf 2017-10-06 7:35 ` Vitaly Kuznetsov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=a6c3be0b-35f4-8d23-4ea2-ead94a3fc69e@oracle.com \ --to=boris.ostrovsky@oracle.com \ --cc=akataria@vmware.com \ --cc=alexander.levin@verizon.com \ --cc=andrew.cooper3@citrix.com \ --cc=bp@alien8.de \ --cc=chrisw@sous-sol.org \ --cc=efault@gmx.de \ --cc=hpa@zytor.com \ --cc=jgross@suse.com \ --cc=jpoimboe@redhat.com \ --cc=jslaby@suse.cz \ --cc=linux-kernel@vger.kernel.org \ --cc=live-patching@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=rusty@rustcorp.com.au \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ --cc=virtualization@lists.linux-foundation.org \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.