Hi Gleb and Paolo,
What about organizing vmx_run() as follows:
static int vmx_run()
{
u32 eax;
bool ret;
vmcs_write(HOST_RSP, get_rsp());
ret = vmlaunch();
while (!ret) {
asm volatile(
"vmx_return:\n\t"
SAVE_GPR
);
eax = exit_handler();
switch (eax) {
case VMX_TEST_VMEXIT:
return 0;
case VMX_TEST_RESUME:
break;
default:
printf("%s : unhandled ret from exit_handler.\n", __func__);
return 1;
}
ret = vmresume();
}
printf("%s : vmenter failed.\n", __func__);
return 1;
}
Arthur
On Fri, Jul 19, 2013 at 8:06 PM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> 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
--
Arthur Chunqi Li
Department of Computer Science
School of EECS
Peking University
Beijing, China
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
