From mboxrd@z Thu Jan 1 00:00:00 1970 From: aq Subject: Re: Xen 3.0 Status update Date: Thu, 28 Jul 2005 13:28:41 +0900 Message-ID: <9cde8bff05072721286069e16f@mail.gmail.com> References: Reply-To: aq Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 7/28/05, Ian Pratt wrote: >=20 > 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. >=20 > Status as of 24 July 2005 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > Summary: We have a couple of annoying bugs, but things are coming > together nicely. >=20 > 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]. >=20 > 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: >=20 > * 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) >=20 > * 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. >=20 > 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. >=20 > Rolling-out XenBus/XenStore is a big project, but is making good > progress. A xen-tools@lists.xensource.com mailing list has been created > to co-ordinate this work, and there's now a focussed effort to complete > it ASAP. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Looking at the various sections of the Xen code base, the following > paragraphs summarize the main issues: >=20 > Tools > =3D=3D=3D=3D=3D >=20 > We need to complete the XenBus/XenStore switchover. Block devices are > basically done Have it checked in yet? >=20 > 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? regards, aq