|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-ia64-devel
RE: [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
 
 |   
 
 | 
    | 
  
  
    |   | 
    |