| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] [XM-TEST] Add support for VMX guests in xm-test
On Fri, 2005-12-09 at 06:33 -0800, Dan Smith wrote:
> EM> I would like to see a separate XFAIL_TESTS_VMX or something like
> EM> that, so that we can indicate which tests currently fail on VMX,
> EM> and a separate DISABLED_TESTS_VMX to indicate those that will
> EM> never pass on VMX. What do you think?
>
> So far, any test that detects that it is unable to run on the current
> hardware SKIPs instead of FAIL. For example, a test that requires
> multiple physical CPUs and detects a single CPU box will call SKIP().
> I think this is better than statically defining it in the Makefile,
> since it's possible that a certain feature may be available later on
> later revisions of VT hardware; the test would be the best place
> (IMHO) to make that determination.
As Dan Smith and I have discussed, our goal was to start by configuring
the system one way or another - either VMX enabled or not. We can
perform checks in the tests themselves to see if VMX is enabled and SKIP
if not appropriate.
We are aiming for running para virt and full virt tests concurrently on
the appropriate hardware. Dan Smith is cleaning up XenDomain.py toward
this goal.
Questions:
1) How shall we do reporting? Should we separate VMX systems from the
current reporting structure? Should there be x86_64 VMX separate from
32bit VMX? I haven't submitted a test yet, because I don't want to drag
down the numbers of para-virt testing.
2) How shall we refer to full-virt and para-virt domains in the future?
DomU vs VMX guest? Since our goal is to test them concurrently on the
appropriate hardware, how shall we refer to them in the tests?
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home