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.
Greetings,
-- Pete
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Pete Zaitcev 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;> 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.Well, when doing migration (especially during migration) maybe the mode is switched ? I know we go into shadow pagetable mode during migration... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 7/7/06, Pete Zaitcev <zaitcev@redhat.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
On 7 Jul 2006, at 03:07, Pete Zaitcev 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.The header includes ''auto_translated_physmap'' indicating that the guest can handle that feature, but does not require it to be enabled. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel