WARNING - OLD ARCHIVES

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

xen-ia64-devel

RE: [Xen-ia64-devel] metaphysical mode

To: "Yang, Fred" <fred.yang@xxxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] metaphysical mode
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Thu, 1 Dec 2005 15:13:33 -0800
Delivery-date: Thu, 01 Dec 2005 23:13:14 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX2CYSRKFg65Y42SMaLa72Va1Q7MgAN5HWAAA97qPAAC7t6AAAGnY+w
Thread-topic: [Xen-ia64-devel] metaphysical mode
I am honestly undecided so let me explain my thoughts.

I am still in favor of testing multiple VHPT solutions.
However, I don't think there are any functionality
reasons why a per-VP VHPT is necessary, it is just
a performance issue, correct?   And while multiple
VHPT solutions may be necessary to accommodate different
use models (e.g. scale-up vs scale-out), the differences
can not be measured unless we have domU stable enough
to benchmark large scale applications and/or capability to
migrate domains between machines AND run SMP-guest.

I am also in favor of cleaning up code and easier
maintenance.  But this code has taken many iterations
to "get it right" and the bugs have been very subtle
(often requiring hours of exercise to reproduce) and
difficult to find/fix.  Anthony's solution may be superior
but I'll wager that it is not perfect; there is likely
to be at least one new corner case bug.  If we are driving
for stability, it seems counter-productive to change
code that fixes a theoretical bug but might introduce
other bugs.

Right now we do not have a very good regression test
process.  Even if we did have one, domU is not yet
stable enough to run it.  I think changes to the HV
that affect low-level operations such as physical mode
should now pass a regression test suite -- especially
if they are not fixing a bug that is blocking progress
on achieving stability.

This is why I think getting domU stable and getting
an automated regression test suite are highest priority
for the community.  Can your team help?

Some in the community have been angry with me for committing
changes that have not been fully tested and cause regressions.
Once you can say "this new code has passed the full regression
suite", it will be much easier for me to commit a change.

Thanks,
Dan

> -----Original Message-----
> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx] 
> Sent: Thursday, December 01, 2005 12:53 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); 
> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-ia64-devel] metaphysical mode
> 
> Dan,
> 
> We understand one approach is to do only needed for performance.  But
> please understand the motivation was meant to consolidate code for
> better maintenance in the future.
> 
> Specific to PSR.it/dt/rt patch, the code actually consolidate 
> code from
> multiple places.  So code size may even be smaller and easier to
> maintain. ;-)  Though para-virt'd domains doesn't uses all of 
> the modes
> but the code sequence can be arranged not to impact 
> para-virt'd domains
> performance.  
> 
> Will you take such patch if we also maintain FAST_* mechanism?
> 
> The reason we like to have correct guest PSR.it/dt/rt is for 
> hooking up
> per-VP VHPT for para-virt'd domains support.  Through this effort,
> Xen/ia64 can have consistent VHPT models for either per-VP or global
> VHPT table support during runtime.  This is very important for the SMP
> work.
> 
> Comments?
> 
> -Fred
> 

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

<Prev in Thread] Current Thread [Next in Thread>