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/
Home Products Support Community News


Re: [Xen-devel] Xen 3.0 Status update

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 3.0 Status update
From: aq <aquynh@xxxxxxxxx>
Date: Thu, 28 Jul 2005 13:28:41 +0900
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Jul 2005 04:27:14 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DSwk9Ec6f0asOlV3Zpti++mYL4jgDore/3lH4CY4f53sXtOfUuzbksNG1XKd3zC/pK9KT6H4KcQv3opLWiBgyUC5/XM2xiK2rbT+qF7LmkLWn2FK5IiXC3stzH26Q1GuZ8+QYviZLhTqcSC3vQ0UUSTPTscmnoZDerV36vRtJNE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D2827F3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <A95E2296287EAD4EB592B5DEEFCE0E9D2827F3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: aq <aquynh@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 7/28/05, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> wrote:
> At OLS we had a couple of "Xen Mini Summit" sessions. Although there
> weren't any formal minutes, here's a rough summary of what we
> discussed/concluded.
> Status as of 24 July 2005
> =========================
> Summary: We have a couple of annoying bugs, but things are coming
> together nicely.
> x86_32p (PAE 16GB) and x86_64 ports are close to being feature complete
> with x86_32. We should be able to ship 3.0.0 with the full feature set
> for these ports. [IA64 and Power are not part of the 3.0.0 release, but
> have actually made good progress anyhow].
> We are going to need to support guest kernels that conform to the Xen
> 3.0 API for quite a few years to come, hence its important that we
> ensure the API is extensible and as easy to make backward compatible as
> possible. This has led to us wanting to work hard to push through a
> couple of API changes that will make life easier in future:
>  * New Time API. This is required for systems with unsyncronized TSCs
> like the IBM Summit systems, and is also good for variable speed CPUs
> (laptops)
>  * Replacing control messages with XenBus/XenStore. Doing backwards
> support of the old control message API would be a *huge* pain, so we're
> really keen to get this incorporated before 3.0.0.
> The new time API has been checked-in by Keir, and seems to be working
> fine for most people, but there is at least one bug report of time
> running fast. Please test.
> Rolling-out XenBus/XenStore is a big project, but is making good
> progress. A xen-tools@xxxxxxxxxxxxxxxxxxx mailing list has been created
> to co-ordinate this work, and there's now a focussed effort to complete
> it ASAP.
> The first phase of testing the 3.0 release can begin before the switch
> to XenStore is complete -- there are plenty of platform related issues
> that can be debugged completely independently. The plan is to do weekly
> 3.0-testing releases until we feel that we're on top of the  bugs being
> found by the development community and would benefit from rolling a
> 3.0.0 release to get wider exposure.
> A very nice regression test infrastructure has been developed that
> should be ready to go live in the next week. We also have a 'TestCD'
> which can be used for automated testing. The aim is to get it run on as
> a wide a variety of machines as possible. The results from both of these
> test tools will appear in a results matrix on the web. The regression
> test infrastructure is able to run sophisticated tests requiring
> co-ordination between multiple virtual machines (e.g. SpecWEB etc). The
> framework is easy to extend and add other tests (such as the ones
> developed by Paul) and  it should be possible to develop it into a
> comprehensive suite. It'll also be possible for others to run the
> nightly tests on 'interesting machines' (e.g. wide SMP's) and have the
> results automatically added to the web matrix.
> The plan is to roll the first 3.0-testing release as soon as there are
> no 'show stopper' bugs in the unstable tree. Unfortunately, the current
> domU networking bug that a number of people have reported probably falls
> into this category. Hopefully we can get a testing release out early
> next week. More help to fix bugs (or isolate the changeset that
> introduces them) would be *greatly* appreciated.
> Although not strictly part of the 3.0 release, one of the most important
> things we need to do is to get the arch-xen patch prepared into a form
> that can be submitted upstream to Andrew/Linus. A couple of great
> volunteers stepped forward, and we need to make this an absoloute
> priority and help them as much as we can.
> Looking at the various sections of the Xen code base, the following
> paragraphs summarize the main issues:
> Tools
> =====
> We need to complete the XenBus/XenStore switchover. Block devices are
> basically done

Have it checked in yet?

> There are a bunch of small outstanding tools issues we need to address:
>  * sanitize all the xm commnds to give them consistent naming and
> parameters
>  * test error paths
>  * split console from xend and replace control messages with XenBus (1st
> part complete)
>  * fix output of 'xm info'

oops, i will re-submit the patch to show xen version. but what is
wrong with "xm info" at the moment?


Xen-devel mailing list