Just a curious question about IDT descriptor type for hypercall. What''s the reason to use interrupt-gate type (14) for hypercall (0x82) on 32bit Xen? Is there any special requirement on interrupt disabled at entrance? Interesting thing is the compat mode on 64bit Xen which use 64bit trap-gate type (15) for hypercall from 32bit guest... Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/5/07 15:43, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Just a curious question about IDT descriptor type for hypercall. What''s > the reason to use interrupt-gate type (14) for hypercall (0x82) on 32bit > > Xen?Everything''s an interrupt gate on 32-bit Xen, so that we can safely (atomically) save away guest segment register state. NMI is the only real pain, and I suppose MCE too. Coincidentally Jan just emailed about this very point. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir@xensource.com] >Sent: 2007年5月15日 23:02 > >On 15/5/07 15:43, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> Just a curious question about IDT descriptor type for hypercall. What''s >> the reason to use interrupt-gate type (14) for hypercall (0x82) on 32bit >> >> Xen? > >Everything''s an interrupt gate on 32-bit Xen, so that we can safely >(atomically) save away guest segment register state. NMI is the only real >pain, and I suppose MCE too. Coincidentally Jan just emailed about this >very >point. > > -- KeirSo why is atomic save required for hypercall here? NMI can break atomic save here for both types, as you said. Normally external interrupt handler doesn''t need communicate with interrupted context. So even when an external interrupt comes in the middle of the guest context save for hypercall (if by trap gate), that interrupted save process can still continue since interrupt handler itself will impose atomic context save/restore on top of interrupted context. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/5/07 16:18, "Tian, Kevin" <kevin.tian@intel.com> wrote:>> Everything''s an interrupt gate on 32-bit Xen, so that we can safely >> (atomically) save away guest segment register state. NMI is the only real >> pain, and I suppose MCE too. Coincidentally Jan just emailed about this >> very point. > > So why is atomic save required for hypercall here? NMI can break > atomic save here for both types, as you said. Normally external > interrupt handler doesn''t need communicate with interrupted > context. So even when an external interrupt comes in the middle > of the guest context save for hypercall (if by trap gate), that > interrupted save process can still continue since interrupt handler > itself will impose atomic context save/restore on top of interrupted > context.Interrupt handlers save and restore segment registers. We could fault on a reload of a segment register and lose the original segment register value. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
In native linux, syscall (gate type 15) and its RESTORE_ALL code provides weak fixup mechanism when reload segment register, by sending 0 selector to ds/es/gs, or kill the process when iret meets problem. Native linux can pay the price with this way since it doesn''t matter when a ring3 process meet problem (and the possibility of doing so is very low). In xen, hypercall (gate type 14) and its restore code provides stronger fixup mechanism by sending more reasonable value to segment registers, since we cannot simply kill a ring 1 guest os kernel process. Type 14 gate of hypercall is used to reduce the risk/possibility of segment register issue. Thanks, Jinsong -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: 2007年5月15日 23:30 To: Tian, Kevin; Keir Fraser; xen-devel@lists.xensource.com Cc: Liu, Jinsong Subject: Re: [Xen-devel] trap/interrupt gate for hypercall On 15/5/07 16:18, "Tian, Kevin" <kevin.tian@intel.com> wrote:>> Everything''s an interrupt gate on 32-bit Xen, so that we can safely >> (atomically) save away guest segment register state. NMI is the only real >> pain, and I suppose MCE too. Coincidentally Jan just emailed about this >> very point. > > So why is atomic save required for hypercall here? NMI can break > atomic save here for both types, as you said. Normally external > interrupt handler doesn''t need communicate with interrupted > context. So even when an external interrupt comes in the middle > of the guest context save for hypercall (if by trap gate), that > interrupted save process can still continue since interrupt handler > itself will impose atomic context save/restore on top of interrupted > context.Interrupt handlers save and restore segment registers. We could fault on a reload of a segment register and lose the original segment register value. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir@xensource.com] >Sent: 2007年5月15日 23:30 > >Interrupt handlers save and restore segment registers. We could fault on >a >reload of a segment register and lose the original segment register >value. > > -- KeirI saw one necessity by always using interrupt gate type, that restore_all_xen can be simplified without segment registers restore. Or else at least ds/es need be restored for restore_all_xen if interrupt happens at entrance of hypercall (if by trap gate type). But I''m weak knowledge about the reason you list. What''s the ability that hypercall handler can do while interrupt handler can''t when reload of a problematic segment register? Anyway interrupt can also raise from guest context and interrupt handle also needs to tackle fault of reloading. Could you kindly give an example? :-) Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/5/07 04:17, "Tian, Kevin" <kevin.tian@intel.com> wrote:> I saw one necessity by always using interrupt gate type, that > restore_all_xen can be simplified without segment registers restore. > Or else at least ds/es need be restored for restore_all_xen if interrupt > happens at entrance of hypercall (if by trap gate type). But I''m weak > knowledge about the reason you list. What''s the ability that hypercall > handler can do while interrupt handler can''t when reload of a > problematic segment register? Anyway interrupt can also raise from > guest context and interrupt handle also needs to tackle fault of > reloading. Could you kindly give an example? :-)Enter Xen on hypercall, immediately take an interrupt, on return from interrupt %es faults on reload. How do we propagate this bad segment register value to the guest via the failsafe callback handler from this context? The bad %es is not yet saved on the outer context''s stack frame. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Please see comment question. -----Original Message----- From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] Sent: 2007年5月16日 14:51 To: Tian, Kevin; Keir Fraser; xen-devel@lists.xensource.com Cc: Liu, Jinsong Subject: Re: [Xen-devel] trap/interrupt gate for hypercall On 16/5/07 04:17, "Tian, Kevin" <kevin.tian@intel.com> wrote:> I saw one necessity by always using interrupt gate type, that > restore_all_xen can be simplified without segment registers restore. > Or else at least ds/es need be restored for restore_all_xen if interrupt > happens at entrance of hypercall (if by trap gate type). But I''m weak > knowledge about the reason you list. What''s the ability that hypercall > handler can do while interrupt handler can''t when reload of a > problematic segment register? Anyway interrupt can also raise from > guest context and interrupt handle also needs to tackle fault of > reloading. Could you kindly give an example? :-)Enter Xen on hypercall, immediately take an interrupt, on return from interrupt %es faults on reload. How do we propagate this bad segment --> the problem is when return from interrupt how %es faults on reload except interrupt handler purposely modify kernel stack? --> example? Jinsong register value to the guest via the failsafe callback handler from this context? The bad %es is not yet saved on the outer context''s stack frame. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Enter Xen on hypercall, immediately take an interrupt, on return from >interrupt %es faults on reload. How do we propagate this bad segment > --> the problem is when return from interrupt how %es faults on reload > except interrupt handler purposely modify kernel stack? --> example?By the guest modifying the referenced descriptor from another vCPU.>register value to the guest via the failsafe callback handler from this >context? The bad %es is not yet saved on the outer context''s stack frame.Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sorry, this email is sent before I join xen-devel lists, and it was automatically sent by sever today. Sorry to disturb you. -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Liu, Jinsong Sent: 2007年5月16日 8:23 To: Keir Fraser; Tian, Kevin; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] trap/interrupt gate for hypercall In native linux, syscall (gate type 15) and its RESTORE_ALL code provides weak fixup mechanism when reload segment register, by sending 0 selector to ds/es/gs, or kill the process when iret meets problem. Native linux can pay the price with this way since it doesn''t matter when a ring3 process meet problem (and the possibility of doing so is very low). In xen, hypercall (gate type 14) and its restore code provides stronger fixup mechanism by sending more reasonable value to segment registers, since we cannot simply kill a ring 1 guest os kernel process. Type 14 gate of hypercall is used to reduce the risk/possibility of segment register issue. Thanks, Jinsong -----Original Message----- From: Keir Fraser [mailto:keir@xensource.com] Sent: 2007年5月15日 23:30 To: Tian, Kevin; Keir Fraser; xen-devel@lists.xensource.com Cc: Liu, Jinsong Subject: Re: [Xen-devel] trap/interrupt gate for hypercall On 15/5/07 16:18, "Tian, Kevin" <kevin.tian@intel.com> wrote:>> Everything''s an interrupt gate on 32-bit Xen, so that we can safely >> (atomically) save away guest segment register state. NMI is the only real >> pain, and I suppose MCE too. Coincidentally Jan just emailed about this >> very point. > > So why is atomic save required for hypercall here? NMI can break > atomic save here for both types, as you said. Normally external > interrupt handler doesn''t need communicate with interrupted > context. So even when an external interrupt comes in the middle > of the guest context save for hypercall (if by trap gate), that > interrupted save process can still continue since interrupt handler > itself will impose atomic context save/restore on top of interrupted > context.Interrupt handlers save and restore segment registers. We could fault on a reload of a segment register and lose the original segment register value. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel