trap/interrupt gate for hypercall

trap/interrupt gate for hypercall

[Tian, Kevin]

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

Re: trap/interrupt gate for hypercall

[Keir Fraser]

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

RE: trap/interrupt gate for hypercall

[Tian, Kevin]

>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.
>
> -- Keir

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.

Thanks
Kevin

Re: trap/interrupt gate for hypercall

[Keir Fraser]

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

RE: trap/interrupt gate for hypercall

[Liu, Jinsong]

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

RE: trap/interrupt gate for hypercall

[Liu, Jinsong]

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

RE: trap/interrupt gate for hypercall

[Tian, Kevin]

>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.
>
> -- Keir

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? :-)

Thanks,
Kevin

Re: trap/interrupt gate for hypercall

[Keir Fraser]

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

RE: trap/interrupt gate for hypercall

[Liu, Jinsong]

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

RE: trap/interrupt gate for hypercall

[Jan Beulich]

>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