From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: Nested events in 64bit mini-OS Date: Sun, 18 Nov 2012 18:43:41 +0100 Message-ID: <20121118174341.GB6017@type> References: <50871D90.50606@gmail.com> <20121025205653.GW5925@type.chello.at> <5098A674.5090203@cs.uic.edu> <20121110135218.GA5436@type> <509FC5F6.4050506@cs.uic.edu> <50A2F8A7.5000202@cs.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <50A2F8A7.5000202@cs.uic.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Xu Zhang Cc: gm281@cam.ac.uk, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Xu Zhang, le Tue 13 Nov 2012 19:49:27 -0600, a =E9crit : > 1. if event is disabled: doesn't hurt to mask it again; > 2. if event is enabled: we disable event, and jumps to hypercall_page to > make a hypercall iret, which eventually calls do_iret: > = > In do_iret, line 309: > /* Restore upcall mask from supplied EFLAGS.IF. */ > vcpu_info(v, evtchn_upcall_mask) =3D !(iret_saved.rflags & > X86_EFLAGS_IF); Ah, right. Disabling events just before the jmp seems all right to me then. > Correct me if I am wrong, I think hypercall_page is mapped at runtime to > guest OS by Xen. It's not actually part of the critical section of guest = OS, > at least not at compile time. Sure. I meant it'd mean a second fixup table, but who knows what code is there, it could be tampering with the stack. > Following the discussion above, we could easily avoid such fixup table > by mask out the events. Completely. Samuel