Re: [RFC PATCH] kvm-unit-tests : Basic architecture of VMX nested test case

[Paolo Bonzini <pbonzini@redhat.com>]

Il 19/07/2013 11:40, Gleb Natapov ha scritto:
>> Because this is written in C, and I know trying to fool the compiler is
>> a losing game.  So my reaction is "okay, HOST_RIP must be set so that
>> code will not jump around".  If I see
>>
>>    asm("vmlaunch")
>>    exit(-1)
>>
>> the reaction is the opposite: "hmm, anything that jumps around would
>> have a hard time with the compiler, there must be some assembly
>> trampoline somewhere; let's check what HOST_RIP is".
>>
> We do try to fool compiler often even without vmx: code patching. This is
> why asm goto was invented, no? So, like you said in previous emails,
> asm goto is appropriate way here to tell compiler what is going on.

Code patching is "only" reimplementing an existing C structure (if/else)
in a different manner.  Here the actual code flow (location of HOST_RIP
and value of HOST_RSP) cannot be expressed correctly to the compiler
because we do not use the C label (we use an asm label).

I don't think asm goto can be made to work for vmx_return, though if we
go for a big blob it could be useful to jump to the error handling code.

>> I don't see anything bad in jumping completely to a different context.
>> The guest and host are sort of like two coroutines, they hardly have any
>> connection with the code that called vmlaunch.
> You can see it as two coroutines, or you can see it as linear logic:
>   do host stuff
>   enter guest
>   do guest stuff
>   exit guest
>   continue doing host stuff
> 
> Both can be implemented, I prefer linear one. I would prefer linear one
> to coroutine in any code design, no connection to vmx. Sometimes
> coroutine are better than alternative (and in those cases alternative is
> never a linear logic), but this is not the case.

Fair enough.

As things stand, we have only one version that works reliably with
past/present/future compilers, and that is the one with setjmp/longjmp.
 A v5 would be needed anyway.  If Arthur (and Jan) want to write the
vmentry as a big asm blob, that's fine by me.  Still, some variety adds
value in a testsuite: think of a hypothetic nested VMX implementation
that ignores HOST_RIP and just falls through to the next host %rip, we
want that to fail the tests! (*)

    (*) In fact, I think this must be a requirement even if Arthur
        goes for a big asm blob.

If they prefer to keep setjmp/longjmp and fix the few remaining nits, I
think that should be acceptable anyway.  It would even make sense to
have multiple vmentries if you can show they stress the hypervisor
differently.

In any case, I think we all agree (Arthur too) that this RFC doing mixed
asm and C is the worst of both worlds.

>>> The actually differences in asm instruction between both
>>> version will not be bigger then a couple of lines (if we will not take
>>> setjmp/longjmp implementation into account :)),
>>
>> I was waiting for this parenthetical remark to appear. ;)
>>
> I've put a smile there :) I realize this argument is not completely fair,
> but for the sake of argument everything goes!

Yes, I caught the irony. ;)

Paolo