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

Re: [Xen-devel] auto_translated_physmap in Fedora

To: "Pete Zaitcev" <zaitcev@xxxxxxxxxx>
Subject: Re: [Xen-devel] auto_translated_physmap in Fedora
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Sat, 8 Jul 2006 10:48:14 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, quintela@xxxxxxxxxx
Delivery-date: Sat, 08 Jul 2006 02:48:37 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jk1vZtSb45g/UyvylPWtj2DUdS2M0AVyyZNyCeQDMev75wGDLm0ppq5kbgxqdcnZjCQE+KkC6KqWa6fZud4gL+oLCG/pkDOx1zHpSG5iB1zSkUv+4v1dpAu017CdbbBD9+u5hczotr1Uc7e2pXf0dgo98MFU+unGacCQLP7ncsM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060706190738.4f611e63.zaitcev@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060706190738.4f611e63.zaitcev@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 7/7/06, Pete Zaitcev <zaitcev@xxxxxxxxxx> wrote:
I noticed one curious thing while working on some issues with Fedora.
At least in 2.6.17-1.2302_FC6xen, the following evaluates to false:

        if (xen_feature(XENFEAT_auto_translated_physmap))
                return pfn;

But the head-xen.S looks like this:

.section __xen_guest
        .ascii  "GUEST_OS=linux,GUEST_VER=2.6"
        .ascii  ",XEN_VER=xen-3.0"
        .ascii  ",VIRT_BASE=0x"; utoh __START_KERNEL_map
        .ascii  ",HYPERCALL_PAGE=0x"; utoh (phys_hypercall_page >> PAGE_SHIFT)
        .ascii  ",FEATURES=writable_page_tables"
        .ascii           "|writable_descriptor_tables"
        .ascii           "|auto_translated_physmap"
        .ascii           "|supervisor_mode_kernel"
        .ascii  ",LOADER=generic"
        .byte   0

Everything continues to work just fine, thanks to runtime checks
of xen_feature() like the above.

So I am curious, if this is something anyone cares about.
Also, why does it happen? If it's a feature which cannot be enabled
(anymore), perhaps we can simply the code and get some performance
by removing the run-time checks.

It can be enabled by passing a feaures value to the domain builder
which enables it.  In its header, the guest advertises which features
it doesn't support (by not listing them), which features it supports
(by listing them) and which features it requires (by listing them
prefixed with a ! -- as used in the upstream patchqueue kernel).  This
leaves some freedom to the user and/or the hypervisor to
enable/disable features they think give better performance and/or do
not exist yet or anymore in the hypervisor.

I don't think you'll get any performance from removing these, most are
on non-critical code patch and we've been careful to make the checks
on any critical path very fast.  That's the main reason why the
feature bits get unpacked within the guest on boot, allowing them to
get or'ed into existing conditions.

   christian

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

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