WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] [XM-TEST] Add support for VMX guests in xm-test

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>, Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [XM-TEST] Add support for VMX guests in xm-test
From: Daniel Stekloff <dsteklof@xxxxxxxxxx>
Date: Fri, 09 Dec 2005 09:34:56 -0800
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Yu, Ping Y" <ping.y.yu@xxxxxxxxx>
Delivery-date: Fri, 09 Dec 2005 17:35:56 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <87d5k6jq5o.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1133993078.6945.8.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20051209111727.GD9336@xxxxxxxxxxxxxxxxxxxxxx> <87d5k6jq5o.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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