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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux