use of setjmp/longjmp in x86 emulator.
in [Kernel]
|
Prev: ARM: includecheck fix for mach-at91/board-sam9m10g45ek.c
Next: 2.6.33: Intel DP55KG - USB still not fixed: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 4 ret -110
From: Gleb Natapov on 2 Mar 2010 02:30 On Mon, Mar 01, 2010 at 02:13:32PM -0500, john cooper wrote: > Gleb Natapov wrote: > > >Think about what happens if in the middle of > >instruction emulation some data from device emulated in userspace is > >needed. Emulator should be able to tell KVM that exit to userspace is > >needed and restart instruction emulation when data is available. > > setjmp/longjmp are useful constructs in general but > IME are better suited for infrequent exceptions vs. > routine usage. Exception condition during instruction emulation _is_ infrequent. Although setjmp/longjmp that I know about are routine usage. See QEMU TCG main loop or userspace thread libraries. > If the issue is finding some clean and regular way > to back out from (and possibly reeneter) logic > expressed within nested function invocations, have > you considered turning the problem inside out and > using a state machine approach? I don't see how state machine will help. But the goal is not to rewrite emulator.c (this will no be excepted by kvm maintainers), but improve it gradually. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gleb Natapov on 2 Mar 2010 03:10 On Mon, Mar 01, 2010 at 01:34:42PM -1000, Zachary Amsden wrote: > On 03/01/2010 12:56 PM, H. Peter Anvin wrote: > >On 03/01/2010 02:31 PM, H. Peter Anvin wrote: > >>On 03/01/2010 11:18 AM, Zachary Amsden wrote: > >>>It's going to be ugly to emulate segmentation, NX and write protect > >>>support without hardware to do this checking for you, but it's just what > >>>you have to do in this slow path - tedious, fully specified emulation. > >>> > >>>Just because it's tedious doesn't mean we need to use setjmp / longjmp. > >>>Throw / catch might be effective, but it's still pretty bizarre to do > >>>tricks like that in C. > >>> > >>Well, setjmp/longjmp really is not much more than exception handling in C. > >> > >For what it's worth, I think that setjmp/longjmp is not anywhere near as > >dangerous as people want to make it out to be. gcc will warn for > >dangerous uses (and a lot of non-dangerous uses), but generally the > >difficult problems can be dealt with by moving the setjmp-protected code > >into a separate function. > > I'd be curious to see if it would need to evolve it to preemptsetjmp > / irqlongjmp or some other more complex forms in time. > Just don't allow stupid usage of longjmp. Like everything else it can be abused. > But I'd rather implement a new language where acquisition of > resources such as locks, dynamically allocated objects, and ref > counts are predicated in the function typing and are heavily > encouraged to possess defined inverses. Then the closure of a > particular layer of nesting already has enough information to > provide release upon escape, and the compiler can easily take the > burden of checking for a large class of lock and resource violation. > > And it would have to be prettier than the current languages that do > that, meaning operator overloading would be banned. Although it > would define rational numbers, super-extended precision arithmetic, > imaginary numbers, quaternions and matrices as part of the spec, so > there would be no need to use arithmetic overrides anyway, and then > all the nonsensical operators could die, die, die, especially the > function () and logical operator overrides. > Will you language have a lot of parentheses? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gleb Natapov on 2 Mar 2010 03:50 On Mon, Mar 01, 2010 at 02:56:59PM -0800, H. Peter Anvin wrote: > On 03/01/2010 02:31 PM, H. Peter Anvin wrote: > > On 03/01/2010 11:18 AM, Zachary Amsden wrote: > >> > >> It's going to be ugly to emulate segmentation, NX and write protect > >> support without hardware to do this checking for you, but it's just what > >> you have to do in this slow path - tedious, fully specified emulation. > >> > >> Just because it's tedious doesn't mean we need to use setjmp / longjmp. > >> Throw / catch might be effective, but it's still pretty bizarre to do > >> tricks like that in C. > >> > > > > Well, setjmp/longjmp really is not much more than exception handling in C. > > > > For what it's worth, I think that setjmp/longjmp is not anywhere near as > dangerous as people want to make it out to be. gcc will warn for > dangerous uses (and a lot of non-dangerous uses), but generally the > difficult problems can be dealt with by moving the setjmp-protected code > into a separate function. > Can I consider this as ACK for something like the patch blow? :) (with proper x86 version of setjmp/longjmp of course). diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index cfcb6f0..089a405 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -35,6 +35,45 @@ #include "x86.h" #include "tss.h" +typedef unsigned long jmp_buf[8]; +int setjmp(jmp_buf); +void longjmp(jmp_buf, int); + +asm ( +" .align 4\n" +" .type setjmp, @function\n" +"setjmp:\n" +" pop %rsi # Return address, and adjust the stack\n" +" xorl %eax,%eax # Return value\n" +" movq %rbx,(%rdi)\n" +" movq %rsp,8(%rdi) # Post-return %rsp!\n" +" push %rsi # Make the call/return stack happy\n" +" movq %rbp,16(%rdi)\n" +" movq %r12,24(%rdi)\n" +" movq %r13,32(%rdi)\n" +" movq %r14,40(%rdi)\n" +" movq %r15,48(%rdi)\n" +" movq %rsi,56(%rdi) # Return address\n" +" ret\n" +" .size setjmp,.-setjmp\n" + +" .align 4\n" +" .type longjmp, @function\n" +"longjmp:\n" +" movl %esi,%eax # Return value (int)\n" +" movq (%rdi),%rbx\n" +" movq 8(%rdi),%rsp\n" +" movq 16(%rdi),%rbp\n" +" movq 24(%rdi),%r12\n" +" movq 32(%rdi),%r13\n" +" movq 40(%rdi),%r14\n" +" movq 48(%rdi),%r15\n" +" jmp *56(%rdi)\n" +" .size longjmp,.-longjmp\n" + ); + +static jmp_buf jb; + /* * Opcode effective-address decode tables. * Note that we only emulate instructions that have at least one memory @@ -1729,7 +1768,7 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt, c->dst.bytes, ctxt->vcpu); if (rc != X86EMUL_CONTINUE) - return rc; + longjmp(jb, 1); break; case OP_NONE: /* no writeback */ @@ -2391,6 +2430,11 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops) memcpy(c->regs, ctxt->vcpu->arch.regs, sizeof c->regs); saved_eip = c->eip; + if (setjmp(jb)) { + printk(KERN_ERR"setjump() == 1\n"); + return 0; + } + if (ctxt->mode == X86EMUL_MODE_PROT64 && (c->d & No64)) { kvm_queue_exception(ctxt->vcpu, UD_VECTOR); goto done; -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 7 Mar 2010 04:10 On 03/02/2010 09:28 AM, Gleb Natapov wrote: > On Mon, Mar 01, 2010 at 02:13:32PM -0500, john cooper wrote: > >> Gleb Natapov wrote: >> >> >>> Think about what happens if in the middle of >>> instruction emulation some data from device emulated in userspace is >>> needed. Emulator should be able to tell KVM that exit to userspace is >>> needed and restart instruction emulation when data is available. >>> >> setjmp/longjmp are useful constructs in general but >> IME are better suited for infrequent exceptions vs. >> routine usage. >> > Exception condition during instruction emulation _is_ > infrequent. Well, with mmio you'd expect it to happen every read access. > Although setjmp/longjmp that I know about > are routine usage. See QEMU TCG main loop or userspace > thread libraries. > Agreed, nothing magical about it. >> If the issue is finding some clean and regular way >> to back out from (and possibly reeneter) logic >> expressed within nested function invocations, have >> you considered turning the problem inside out and >> using a state machine approach? >> > I don't see how state machine will help. But the goal > is not to rewrite emulator.c (this will no be excepted > by kvm maintainers), but improve it gradually. > That is orthogonal. If we decide a state machine is the best implementation, then we'll find a way to move over to that. However, I don't think a state machine is a good representation considering some of the code paths are very complicated and depend on a many memory accesses (e.g. hardware task switches). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 7 Mar 2010 04:10
On 03/02/2010 10:49 AM, Gleb Natapov wrote: > On Mon, Mar 01, 2010 at 02:56:59PM -0800, H. Peter Anvin wrote: > >> On 03/01/2010 02:31 PM, H. Peter Anvin wrote: >> >>> On 03/01/2010 11:18 AM, Zachary Amsden wrote: >>> >>>> It's going to be ugly to emulate segmentation, NX and write protect >>>> support without hardware to do this checking for you, but it's just what >>>> you have to do in this slow path - tedious, fully specified emulation. >>>> >>>> Just because it's tedious doesn't mean we need to use setjmp / longjmp. >>>> Throw / catch might be effective, but it's still pretty bizarre to do >>>> tricks like that in C. >>>> >>>> >>> Well, setjmp/longjmp really is not much more than exception handling in C. >>> >>> >> For what it's worth, I think that setjmp/longjmp is not anywhere near as >> dangerous as people want to make it out to be. gcc will warn for >> dangerous uses (and a lot of non-dangerous uses), but generally the >> difficult problems can be dealt with by moving the setjmp-protected code >> into a separate function. >> >> > Can I consider this as ACK for something like the patch blow? :) (with > proper x86 version of setjmp/longjmp of course). > The setjmp/longjmp implementation should definitely live in arch/*/lib, even if kvm is the only user. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |