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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
