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.
From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
Sent: 2007年5月15日 23:30
To: Tian, Kevin; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
Cc: Liu, Jinsong
Subject: Re: [Xen-devel] trap/interrupt gate for hypercall
On 15/5/07 16:18, "Tian, Kevin" <kevin.tian@xxxxxxxxx> 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
Interrupt handlers save and restore segment registers. We could fault on a
reload of a segment register and lose the original segment register value.
Xen-devel mailing list