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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On 12/19/16 16:34 +0000, Andrew Cooper wrote:
> 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.
OK. Right now let me organize these test cases by instructions,
e.g. test-hvm64-vvmxon, test-hvm64-vvmxoff, etc.

> > > 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.
Yes, that is what I'm going to follow.

> > > * 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.
make sense

> 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.
Ah yes, for the live migration! Thanks for the explanation.

Thanks,
Haozhong

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