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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/12/16 05:31, Haozhong Zhang wrote:
> On 12/16/16 21:26 +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 for this series.  I have reviewed it now, and have no major
>> problems.  It is in quite good shape, other than the licensing concerns
>> with patch 4.
>>
>> One limitation (because I haven't gotten around to implementing it yet)
>> is that once a test is accepted, it can't be logically extended, because
>> it isn't bisection-safe as far as OSSTest is concerned.
>>
>
> I'm going to add more test cases in the process of fixing nested VMX,
> so I think I'd better to put each case in a single test, instead of
> all cases in one test-hvm64-vvmx.

Ah - this clarifies what you mean by dependences of tests on the other
thread.

At the moment there is an implicit dependency used by both automated
test systems running XTF at the moment, which says that a test-$ENV-$foo
shouldn't be run if the test-$ENV-selftest didn't complete successfully.

I haven't yet encountered a need for other tests to be co-dependent. 
Let me consider how this might be made to work.

>
>> I will prioritise my work to introduce the test-revision plan, which
>> will allow the OSSTest bisector to work properly in the case that new
>> functionality in a test causes a previously-passing scenario to now
>> fail.
>>
>> Is this a complete set of vmxon scenarios, or are you working on more?
>> Some which come to mind are:
>>
>> * a register operand (to check that Xen decodes properly and rejects the
>> instruction)
>
> I'll add this one, and
>
> * vmxon w/ nestedhvm=0.

You should probably look into using a test variation to explicitly set
the test configuration to =0 and =1

See the invlpg and pv-iopl tests for examples of this.

>
>> * duplicate vmxon in root operation
>>
>> Another area I had on my nested-virt plan was to allow rather finer
>> grain configuration of the vmx options, but that depends on the start of
>> the MSR levelling work, which is still blocked behind getting enough
>> time to finish the CPUID levelling plans.
>>
>
> I'll keep this possible change in my mind while I'm preparing test
> cases which use CPUID/MSR/... to detect the environment instead of
> replying on assumptions only satisfied on the current Xen implementation.
>
>> In particular, I eventually want an ability for fine-grained toolstack
>> settings of the available VMX configuration (these being a subset of the
>> MSRs in the system), (all subject to auditing by Xen to keep it within
>> hardware and supported bounds), at which point it would be plausible to
>> spin up a VM, asking for VMX_BASIC_32BIT_ADDRESSES, and checking that
>> suitable limits were observed/enforced inside the VM.
>>
>
> I do not quite understand the purpose for the fine-grained VMX
> options. Is it to provide users with a chance to workaround bugs in
> certain parts of nested virtualization?

I have two usecases in mind.

First is being able to check that Xen functions correctly when certain
VMX features are unavailable.  Recently, we have found a number of
security issues which only affect older hardware, and older hardware is
getting harder and harder to come by.  Using fine grained features can
simulate older hardware in some cases.

Second, and more importantly, that I need to eventually make this all
work with live migration, including between non-identical hardware. 
Therefore, the fine-grained nature would be used to implement feature
levelling.

~Andrew

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