[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] auto_translated_physmap in Fedora
- To: "Pete Zaitcev" <zaitcev@xxxxxxxxxx>
- 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=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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
|
