From: Paolo Bonzini <pbonzini@redhat.com>
To: Arthur Chunqi Li <yzt356@gmail.com>
Cc: Gleb Natapov <gleb@redhat.com>, kvm <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@web.de>
Subject: Re: [PATCH] kvm-unit-tests : The first version of VMX nested test case
Date: Tue, 16 Jul 2013 19:24:05 +0200 [thread overview]
Message-ID: <51E581B5.50200@redhat.com> (raw)
In-Reply-To: <CABpY8MKNfOb9C0sVzyGO4jF4AfFid1tg9ZROWOpkaCxWK=uy+w@mail.gmail.com>
Il 16/07/2013 19:13, Arthur Chunqi Li ha scritto:
> On Wed, Jul 17, 2013 at 12:45 AM, Gleb Natapov <gleb@redhat.com> wrote:
>> On Tue, Jul 16, 2013 at 11:29:20PM +0800, Arthur Chunqi Li wrote:
>>> On Tue, Jul 16, 2013 at 11:20 PM, Gleb Natapov <gleb@redhat.com> wrote:
>>>> On Tue, Jul 16, 2013 at 12:28:05PM +0200, Paolo Bonzini wrote:
>>>>>> +void vmx_exit(void)
>>>>>> +{
>>>>>> + test_vmxoff();
>>>>>> + printf("\nSUMMARY: %d tests, %d failures\n", tests, fails);
>>>>>> + exit(fails ? -1 : 0);
>>>>>> +}
>>>>>
>>>>> Can you try to jump back to main, and do test_vmxoff there? This will
>>>>> avoid having to write our tests in callback style, which is a pain.
>>>>> Basically something similar to setjmp/longjmp. In main:
>>>>>
>>>>> if (setjmp(jmpbuf) == 0) {
>>>>> vmx_run();
>>>>> /* Should not reach here */
>>>>> report("test vmlaunch", 0);
>>>>> }
>>>>> test_vmxoff();
>>>>>
>>>>> exit:
>>>>> printf("\nSUMMARY: %d tests, %d failures\n", tests, fails);
>>>>> return fails ? 1 : 0;
>>>>>
>>>>> In vmx_handler:
>>>>>
>>>>> case VMX_HLT:
>>>>> printf("\nVM exit.\n");
>>>>> longjmp(jmpbuf, 1);
>>>>>
>>>> Why not just make vmexit occur after vmlaunch/vmresume like KVM does. It
>>>> will make code much more straightforward and easer to follow.
>>> The concept "easier to follow" may have different meanings in
>>> different view. This achievement puts all the test cases in main
>>> function instead of scattering everywhere, which is another view to
>>> "easy to follow". As this is just a test case, I prefer this one.
>>>
>> I do not see why what I propose will prevent you to put all tests into main.
>>
>> vmx_run() will looks like that:
>>
>> vmlaunch
>> while(1) {
>> vmresume
>> <---- vmexit jumps here
>> switch(exit reason) {
>> case reason1:
>> break;
>> case reason2:
>> break;
>> case HLT
>> return;
>> }
>> }
> Yes, this recalls me some KVM codes I have read before. This mixes
> vmlaunch/resume and vmx_handler into one piece of code. It is a good
> way to explicitly show the execution sequence though, it increases LOC
> in one function.
>>
>>> Besides, this way we can start another VM following the previous one
>>> simply in main function. This is flexible if we want to test re-enter
>>> to VMX mode or so.
>>>
>> That's what I am missing. How do one writes more tests now?
>>
>> I was thinking about interface like that:
>>
>> guest_func_test1()
>> {
>> }
>>
>> tes1t_exit_handlers[] = {test1_handle_hlt, test1_handle_exception, ....}
>>
>> main()
>> {
>>
>> init_vmcs(); /* generic stuff */
>> init_vmcs_test1(); /* test1 related stuff */
>> r = run_in_guest(guest_func_test1, test1_exit_handlers);
>> report("test1", r);
>> }
>>
> I have thought about this question and I'm not quite sure how to solve
> it now.
Why can't you just use a different vmx_handler (e.g. with an indirect
call in entry_vmx) for each test (as in Gleb's test1_exit_handlers)?
run_in_guest would prepare the function pointers and do
init_vmcs(&vmcs_root);
if (setjmp(env) == 0){
vmx_run();
/* Should not reach here */
report("test vmlaunch", 0);
}
as in your current testcase.
vmx.c would be a "library", and testcases could be either grouped in the
same file or spread across many of them, as you see fit.
Paolo
next prev parent reply other threads:[~2013-07-16 17:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 9:27 [PATCH] kvm-unit-tests : The first version of VMX nested test case Arthur Chunqi Li
2013-07-16 9:35 ` Arthur Chunqi Li
2013-07-16 9:45 ` Gleb Natapov
2013-07-16 9:53 ` Arthur Chunqi Li
2013-07-16 9:58 ` Gleb Natapov
2013-07-16 10:28 ` Paolo Bonzini
2013-07-16 11:47 ` Arthur Chunqi Li
2013-07-16 11:58 ` Paolo Bonzini
2013-07-16 15:20 ` Gleb Natapov
2013-07-16 15:29 ` Arthur Chunqi Li
2013-07-16 16:45 ` Gleb Natapov
2013-07-16 17:13 ` Arthur Chunqi Li
2013-07-16 17:24 ` Paolo Bonzini [this message]
2013-07-16 17:47 ` Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E581B5.50200@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=yzt356@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.