From: Gleb Natapov on
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
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
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
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
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/