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

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

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.

> 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.

> * 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?

Thanks,
Haozhong

> Now, the above is part of some larger issues I need to fix for
> XenServer, and I am not suggesting or hinting for you to do any of the
> work  (This is a multi-year plan on my behalf).  However, I hope it
> helps to see where I am trying to get to in the long term.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel