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 1 Mar 2010 04:20 I am looking at improving KVM x86 emulator. Current code does not handle some special cases correctly (code execution from ROM, ins/outs to/from MMIO) and many exception conditions during instruction emulation are not handled correctly. There is a lot of code in emulator that is there only for exception propagation. Using setjmp/longjmp will be very beneficial here as exception condition during instruction execution maps very naturally to setjmp/longjmp, so my question is what about adding setjmp/longjmp implementation to the kernel, or alternatively, if there is a fear that it can be abused, add it locally to emulator.c? Note that instruction emulation is always done in process context. -- 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 1 Mar 2010 08:00 On Mon, Mar 01, 2010 at 09:45:46PM +0900, Takuya Yoshikawa wrote: > Gleb Natapov wrote: > >I am looking at improving KVM x86 emulator. Current code does not > > Does your plan also include making the emulator independent of KVM? Yes, I am planning to make it more independent from KVM that it is now (by adding more callbacks to x86_emulate_ops). > Could you tell me about the future plan if possible? > We saw a lot of problems and shortcomings in the emulator recently, so the plan is to improve its correctness. There is also a requirement to be able single step emulated code. Having setjmp/longjmp will greatly simplify the code. What are you interested in? > >handle some special cases correctly (code execution from ROM, ins/outs > >to/from MMIO) and many exception conditions during instruction emulation > >are not handled correctly. There is a lot of code in emulator that is > >there only for exception propagation. Using setjmp/longjmp will be very > >beneficial here as exception condition during instruction execution > >maps very naturally to setjmp/longjmp, so my question is what about > >adding setjmp/longjmp implementation to the kernel, or alternatively, > >if there is a fear that it can be abused, add it locally to emulator.c? > >Note that instruction emulation is always done in process context. > > > >-- > > 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/ -- 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: Takuya Yoshikawa on 1 Mar 2010 08:20 Gleb Natapov wrote: > I am looking at improving KVM x86 emulator. Current code does not Does your plan also include making the emulator independent of KVM? Could you tell me about the future plan if possible? > handle some special cases correctly (code execution from ROM, ins/outs > to/from MMIO) and many exception conditions during instruction emulation > are not handled correctly. There is a lot of code in emulator that is > there only for exception propagation. Using setjmp/longjmp will be very > beneficial here as exception condition during instruction execution > maps very naturally to setjmp/longjmp, so my question is what about > adding setjmp/longjmp implementation to the kernel, or alternatively, > if there is a fear that it can be abused, add it locally to emulator.c? > Note that instruction emulation is always done in process context. > > -- > 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/ -- 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 1 Mar 2010 08:40 On Mon, Mar 01, 2010 at 10:17:21PM +0900, Takuya Yoshikawa wrote: > Gleb Natapov wrote: > >On Mon, Mar 01, 2010 at 09:45:46PM +0900, Takuya Yoshikawa wrote: > >>Gleb Natapov wrote: > >>>I am looking at improving KVM x86 emulator. Current code does not > >>Does your plan also include making the emulator independent of KVM? > >Yes, I am planning to make it more independent from KVM that it is now > >(by adding more callbacks to x86_emulate_ops). > > > >>Could you tell me about the future plan if possible? > >> > >We saw a lot of problems and shortcomings in the emulator recently, so > >the plan is to improve its correctness. There is also a requirement to be > >able single step emulated code. Having setjmp/longjmp will greatly simplify > >the code. What are you interested in? > > I am mainly interested in clearly understanding the KVM x86 emulator. > > In that sense, what I felt first was it's impossible to understand why > it is working without the deep(whole) knowledge of the KVM's architecture. > If emulator itself is self contained, it will be much help for me. You will need some knowledge of KVM in any case since KVM design shapes emulator design. 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. > > Though I do not think every instruction should be implemented, it would be > nice if each instruction emulated is independent of KVM: if we can check the > validity of them using only SDM, it would be really nice! > Agree. That is my goal too. > Thanks, > Takuya > > > > >>>handle some special cases correctly (code execution from ROM, ins/outs > >>>to/from MMIO) and many exception conditions during instruction emulation > >>>are not handled correctly. There is a lot of code in emulator that is > >>>there only for exception propagation. Using setjmp/longjmp will be very > >>>beneficial here as exception condition during instruction execution > >>>maps very naturally to setjmp/longjmp, so my question is what about > >>>adding setjmp/longjmp implementation to the kernel, or alternatively, > >>>if there is a fear that it can be abused, add it locally to emulator.c? > >>>Note that instruction emulation is always done in process context. > >>> > >>>-- > >>> 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/ > > > >-- > > Gleb. -- 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: Zachary Amsden on 1 Mar 2010 11:20
On 02/28/2010 11:18 PM, Gleb Natapov wrote: > I am looking at improving KVM x86 emulator. Current code does not > handle some special cases correctly (code execution from ROM, ins/outs > to/from MMIO) and many exception conditions during instruction emulation > are not handled correctly. There is a lot of code in emulator that is > there only for exception propagation. Using setjmp/longjmp will be very > beneficial here as exception condition during instruction execution > maps very naturally to setjmp/longjmp, so my question is what about > adding setjmp/longjmp implementation to the kernel, or alternatively, > if there is a fear that it can be abused, add it locally to emulator.c? > Note that instruction emulation is always done in process context. > I'm all for radical ideas, but from a pragmatic point of view, you shouldn't use longjmp in the kernel. Seriously bad things are happening with it; it leaves local variables undefined, doesn't undo global state changes. So if you: spin_lock(&s->lock); if (!s->active) longjmp(buf, -1); .... you are broken. This case can be made very much more complex and hard to reason about by using local variables which are reset by the longjmp. Further, it requires use of the volatile keyword to interact properly with logic involving more than one variable, and thus, by definition is impossible to use in the kernel, which does not implement the volatile keyword. :) Instead, for this case, use the fact that there is an architecturally designed finite number of exceptions that can be processed simultaneously. This means if you queue exceptions to a pending list of control-flow interrupting events to be processed, as long as the queue is appropriately sized, you will never overflow this queue and never require dynamic allocation. Further, you can then naturally follow the exception priority rules at the top-level of the emulator and never need to pass back complex exception structures, merely a simple return value which indicates whether to return to top-level control logic or continue with instruction emulation. I believe using this style of programming will make your need for setjmp/longjmp go away. Zach -- 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/ |