|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|