We''re, while porting the kernel code back to SLES9, running into a case where the failsafe callback gets entered. Looking at that code we don''t seem to be able to understand how it is actually expected to work. That code, out of load_segments, stores the selectors (including one or more that failed) into the (extended) frame for the kernel to pick them up. The kernel code, however, simply re-does the load of these selectors - how can that be expected to work any better than in the hypervisor? Further, the kernel blindly loads fs and gs, without caring to destroy their base addresses and, even more importantly, its own ability to access the PDA. Any clarification would be greatly appreciated. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27 Mar 2006, at 22:57, Jan Beulich wrote:> We''re, while porting the kernel code back to SLES9, running into a > case where the > failsafe callback gets entered. Looking at that code we don''t seem to > be able to > understand how it is actually expected to work. That code, out of > load_segments, > stores the selectors (including one or more that failed) into the > (extended) frame > for the kernel to pick them up. The kernel code, however, simply > re-does the load > of these selectors - how can that be expected to work any better than > in the > hypervisor? Further, the kernel blindly loads fs and gs, without > caring to destroy > their base addresses and, even more importantly, its own ability to > access the PDA.Xen allows the kernel to do something smarter if it wants, but the correct thing in Linux is to simply zero invalid selectors, so that''s what the failsafe callback handler does. The reload into %gs is indeed bogus -- it should instead HYPERVISOR_set_segment_base(SEGBASE_GS_USER_SEL, gs). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 27 Mar 2006, at 22:57, Jan Beulich wrote: > >> We''re, while porting the kernel code back to SLES9, running into a >> case where the failsafe callback gets entered. Looking at that code >> we don''t seem to be able to understand how it is actually expected >> to work. That code, out of load_segments, stores the selectors >> (including one or more that failed) into the (extended) frame for >> the kernel to pick them up. The kernel code, however, simply re-does >> the load of these selectors - how can that be expected to work any >> better than in the hypervisor? Further, the kernel blindly loads fs >> and gs, without caring to destroy their base addresses and, even >> more importantly, its own ability to access the PDA. > > Xen allows the kernel to do something smarter if it wants, but the > correct thing in Linux is to simply zero invalid selectors, so that''s > what the failsafe callback handler does. The reload into %gs is indeed > bogus -- it should instead > HYPERVISOR_set_segment_base(SEGBASE_GS_USER_SEL, gs). > > -- Keir > >Frankly I don''t think the failsafe callback code is expected to work. I did not see failsafe callback triggered in normal cases or did not have test cases for that at the initial port. When I actually saw it, it was caused by a porting bug in x86-64 XenLinux. If you have a valid case where the failsafe callback should handle, we should fix it. Jun --- Intel Open Source Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27 Mar 2006, at 23:36, Keir Fraser wrote:>> We''re, while porting the kernel code back to SLES9, running into a >> case where the >> failsafe callback gets entered. Looking at that code we don''t seem to >> be able to >> understand how it is actually expected to work. That code, out of >> load_segments, >> stores the selectors (including one or more that failed) into the >> (extended) frame >> for the kernel to pick them up. The kernel code, however, simply >> re-does the load >> of these selectors - how can that be expected to work any better than >> in the >> hypervisor? Further, the kernel blindly loads fs and gs, without >> caring to destroy >> their base addresses and, even more importantly, its own ability to >> access the PDA. > > Xen allows the kernel to do something smarter if it wants, but the > correct thing in Linux is to simply zero invalid selectors, so that''s > what the failsafe callback handler does. The reload into %gs is indeed > bogus -- it should instead > HYPERVISOR_set_segment_base(SEGBASE_GS_USER_SEL, gs).Actually, I think that segment reload portion of the failsafe handler can be got rid of entirely since Xen will already zero an unloadable segment register, plus Xen has all the logic right to make sure that base addresses are preserved. So, as you say, the Linux attempt to load those segment registers really can do no good. :-) I''ll fix that in -unstable. Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27 Mar 2006, at 23:46, Nakajima, Jun wrote:> Frankly I don''t think the failsafe callback code is expected to work. I > did not see failsafe callback triggered in normal cases or did not have > test cases for that at the initial port. When I actually saw it, it was > caused by a porting bug in x86-64 XenLinux. If you have a valid case > where the failsafe callback should handle, we should fix it.It can be triggered, for example by an application that creates an LDT, sets %gs to refer to an entry in the LDT, then zaps that LDT entry. I wouldn''t expect it ever to be triggered in ''normal'' operation though. But if it''s buggy it must be fixed. Fortunately, I think Jan is right and it is fixed merely by deleting lines of code. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>The reload into %gs is indeed bogus -- it should instead >HYPERVISOR_set_segment_base(SEGBASE_GS_USER_SEL, gs).... and then perhaps also for %fs (though I see there is no hypercall for that, so this is going to be more complicated, given that this happens in an assembly file), and perhaps avoiding the two loads altogether if the selectors are zero and their present values are also zero, to prevent trampling on any base values in effect. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel