[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.