From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Re: [PATCH 10/10] KVM: Adds support for halting in the kernel Date: Thu, 24 May 2007 08:43:58 -0400 Message-ID: <46555021.BA47.005A.0@novell.com> References: <20070523130905.23177.11087.stgit@novell1.haskins.net> <20070523131932.23177.38587.stgit@novell1.haskins.net> <46554CFF.9040101@qumranet.com> <46554473.BA47.005A.0@novell.com> <46558266.90309@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Avi Kivity" Return-path: In-Reply-To: <46558266.90309-atKUWr5tajBWk0Htik3J/w@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org So as long as any appropriate signal will kick the HLT out of this wait-queue, we are ok. It sounds like I can just get rid of the sigprocmask all together and this will work? If so, I will pull that out for the "v8" drop I am about to make (rebased on git-head) >>> On Thu, May 24, 2007 at 8:17 AM, in message <46558266.90309-atKUWr5tajBWk0Htik3J/w@public.gmane.org>, Avi Kivity wrote: > Gregory Haskins wrote: >> >> >>> We have a specialized signal mask for the kernel, and it is already in >>> effect here. See KVM_SET_SIGNAL_MASK. >>> >>> >> >> KVM_SET_SIGNAL_MASK is precisely what I was trying to counteract ;). > Basically I was thinking that userspace could have set some arbitrary mask > that would be in effect at this time. My justification for unmasking > everything is two fold: >> >> 1) I think I really want *any* signal to kick the HLT, so I temporarily > unmask everything while halted. >> > > Signals are not yours, they're the user's. You can't return to the user > with a signal if they're not prepared to handle it. > >> 2) Old userspace halting would not have the SET_SIGNAL_MASK set at the time > either, since we would have restored the original mask before returning to > userspace. >> > > That's okay, old userspace won't have masked signals anyway. > > The purpose of having a different signal mask for the kernel and for > userspace (which is what KVM_SET_SIGNAL_MASK does) is to be able to use > signals without signal delivery (which is slow): > > - while in userspace, signals are blocked > - enter kernel, unblock specified signals > - signal happens, restore signal mask, return to userspace > - userspace sees EINTR (bit signal is not delivered); can now use > sigwait() to dequeue signal and process it. > > Without KVM_SET_SIGNAL_MASK, the signal handler is invoked for any > unblocked signals. That's what current qemu wants; but we shall change > it one day. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/