From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location Date: Thu, 22 Feb 2007 15:29:01 +0200 Message-ID: <45DD9A9D.4060500@qumranet.com> References: <45D979D3.2020907@qumranet.com> <20070219103052.4D23725016B@il.qumranet.com><20070221103733.GI3945@ucw.cz> <45DD6CF0.3010509@qumranet.com> <64F9B87B6B770947A9F8391472E032160A91BAF3@ehost011-8.exch011.intermedia.net> <1172140490.3531.236.camel@laptopd505.fenrus.org> <45DD7330.1030001@qumranet.com> <1172142081.3531.243.camel@laptopd505.fenrus.org> <45DD94D3.4030102@qumranet.com> <1172149924.3531.260.camel@laptopd505.fenrus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, akpm-3NddpPZAyC0@public.gmane.org, Pavel Machek , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arjan van de Ven Return-path: In-Reply-To: <1172149924.3531.260.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> 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 Arjan van de Ven wrote: >> Somthing else that came up in a conversation with Dor: the need for a >> clean way to raise a guest interrupt. The guest may be sleeping in >> userspace, scheduled out, or running on another cpu (and requiring an >> ipi to get it out of guest mode). >> > > yeah it'd be nice if I could just call a function for it rather than > poking into kvm internals ;) > > Sure. Please report all inconveniences (they're really bugs) so we can fix them. Poking at kvm internals means you waste your time learning them, and later we can't change them. >> Right now I'm thinking about using the signal machinery since it appears >> to do exactly the right thing. >> > > signals are *expensive* though. > > I think the expensive part of signals is userspace delivery. If they are always blocked in userspace, they become just another IPC channel. I plan to add a signal mask to KVM_RUN a la pselect() so that userspace can dequeue signals instead of using a signal handler. > If you design an interrupt interface, it'd rock if you could make it > such that it is "raise interrupt within miliseconds from > now", rather than making it mostly synchronous. That way irq mitigation > becomes part of the interface rather than having to duplicate it all > over the virtual drivers... > Can't it be done by a helper function using a timer and a signal (or whatever mechanism we use to wake up vcpus)? -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV