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


[Xen-ia64-devel] RE: [PATCH 5/5] Implement guest_os_type for ia64

To: "Zhang, Xing Z" <xing.z.zhang@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: [PATCH 5/5] Implement guest_os_type for ia64
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Tue, 27 Nov 2007 23:59:47 -0700
Cc: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Nov 2007 23:00:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DEEAF066@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: OSLO R&D
References: <1196223655.19478.48.camel@lappy> <823A93EED437D048963A3697DB0E35DEEAF066@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2007-11-28 at 14:36 +0800, Zhang, Xing Z wrote:
> I really directly use copy/parse , thx for collecting me.
> My purpose to use arch_setup for two reasons:
> 1. Do little change in common code.
> 2. I think building tools should not know much about how
> to set identify mapping. It only needs tell XEN which region 
> should be identify mapping. 
> Of course, your implantation is more flexible, both method are ok for me.  

Hi Wing,

   Thanks for reviewing and confirming the UC vs WB change.  The
arch_setup does reduce the change to common code, but it adds an
architecture specific flag to a field that is currently architecture
neutral.  There are already architecture specific domctls, and other
architectures could choose to use the set_opt_feature we've defined with
different structure fields.  It seems more natural and tunable to me to
let the builder code specifically set the identity mappings.  I like
that the entire opt_feature interface is exposed and we can tune it and
experiment without rebooting a new hypervisor (at least for the set of
optimizations we've defined so far).  Anyone else have a strong opinion?


Alex Williamson                             HP Open Source & Linux Org.

Xen-ia64-devel mailing list