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

RE: [Xen-ia64-devel] Next phase of Xen/ia64 development...


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Yang, Fred" <fred.yang@xxxxxxxxx>
  • Date: Sun, 27 Nov 2005 14:03:51 -0800
  • Delivery-date: Sun, 27 Nov 2005 22:03:36 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcXwbWImh55Q6r0QRTW7mhUdOVw9wQDKy8iQ
  • Thread-topic: [Xen-ia64-devel] Next phase of Xen/ia64 development...

Following 2 items should be there for next stages to work forward

1. Enable complete VHPT solution, with option of either global or pev-VP
VHPT choice, for system - this is the effort we are now working toward.
This is a must for the next stage SMP effort.  Please see the previous
discussion thread
http://lists.xensource.com/archives/html/xen-ia64-devel/2005-05/msg00034
.html

2. PMT table support for Domain0 - This is also the effort must happen
to get to Xen/ia32 similar functionality and remove each extra upstream
merge to make ia64 implementation more aligned to Xen, directly
contribute to VBD/VNIC.  Some community member must already looking into
this effort now.  Please see previous discussion
http://lists.xensource.com/archives/html/xen-ia64-devel/2005-11/msg00022
.html

-Fred

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> There have been a number of solid contributions by many people
> to get Xen/ia64 to where it is today.  You should all be very proud!
> 
> I believe the next phase of Xen/ia64 development will need
> to be focused on the end user of Xen/ia64.  What can we do
> to put a useful Xen/ia64 into the hands of Itanium system
> owners who want the functionality of Xen, but who are not
> interested in development or tracking the latest upstream
> changes?
> 
> The top areas of development might be:
> 
> 1) Stable domU.  As some have noticed, domU is currently capable
>    of getting to a single-user shell prompt and executing simple
>    commands but, if it is exercised much, various programs crash
>    possibly killing the guest, and in some cases even killing dom0.
>    This is unacceptable for a "normal user".  There are probably
>    a few bugs in the virtual drivers and hypervisor, but these
>    may be difficult to track down.  We developers need to work
>    together to identify reproducible test cases to help isolate
>    and fix them.
> 2) Networking.  A system without networking has little value to
>    a real user.  Most of the netback/netfront code should be fully
>    leveragable.  We need only identify the few changes necessary
>    to adapt to ia64 differences.  The patch I posted earlier
>    this week should help us to move in the right direction.
> 3) A good regression test environment.  Many of the bugs we
>    are fixing are subtle corner cases which occur very rarely.
>    When fixing these, it is very possible that another bug
>    will be introduced that only occurs in another subtle
>    corner case.  We need to ensure that we continue forward
>    progress.
> 
> Once domU is usable to run real applications and networking is
> working and stable, I think the next steps are:
> 
> 4) SMP guest support
> 5) Migration support
> 6) Performance tuning
> 
> but these will be difficult (and ultimately futile) to work on
> without the stability and networking.
> 
> Comments?
> 
> Dan
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

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