Re: [Xen-devel] [XTF PATCH 00/16] Add test cases for nested vmxon

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/12/16 01:44, Haozhong Zhang wrote:
> On 12/16/16 14:12 +0000, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> This patch series starts to add a test selection "test-hvm64-vvmx" for
>>> nested VMX. This first series focuses mostly on nested vmxon.
>>>
>>> * Patch 01 - 03 test the basic environment (cpuid and MSR).
>>>
>>> * Patch 04 - 05 add functions to execute VMX instructions and to
>>>   collect and handle errors.
>>>
>>> * Patch 06 - 16 construct a bunch of test cases for nested vmxon per
>>>   its pseudo code in section "VMXON - Enter VMX Operation" of Intel
>>>   SDM Vol 3.
>>
>> Thankyou very much for contributing this.
>>
>> As a general question though, how have you found using XTF?  I am eager
>> for any feedback, especially if you found problem areas.
>>
>
> Lars Kurth and George Dunlap visited out site recently and mentioned
> XTF. When I started to look at and fix nested VMX bugs, I used KVM as
> L1 hypervisor. However, KVM is sometimes too heavy and not quite
> controllable for the quick verification and test, so I turned to XTF and
> found it was exactly what I wanted for this purpose.
>
> So far I feel XTF is pretty handy for me to construct quick and short
> test cases for VMX instructions.

This reason is precisely why I developed it to start with.  I now find
that I do almost all my debugging and development work with it.

>
> One feature I desire is to configure the dependency among tests. Take
> this patch series as an example: some tests in patch 09 - 16 make
> sense only when VMX is available. If I can indicate they depend on the
> successful result of tests in patch 01 - 03, then I can separate patch
> 01 - 03 and patch 09 - 16 into two test selections, and will not need
> to introduce additional code in patch 09 - 16 to check the availability
> of VMX.

Do you mean dependencies between specific test functions?

From XTF's point of view, each microkernel constitutes a single test
with an overall result, which typically consists of multiple test
steps.  Within a single microkernel, you are free to make some of the
test steps conditional.

Particularly when testing bits which differ subtly between Intel and
AMD, I find it common to have test steps conditional on cpu_has_*.  One
thing I tend to do which I notice you haven't is that I tend to have a
printk() before major test steps so in the success case, there is a bit
of a log of what was tested.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel