From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gregory Haskins" Subject: Fwd: Re: Status of SMP? Date: Tue, 13 Mar 2007 11:47:21 -0400 Message-ID: <45F68F51.BA47.005A.0@novell.com> References: <45F66525.BA47.005A.0@novell.com> <45F6A426.9090004@qumranet.com> <45F67F12.BA47.005A.0@novell.com> <45F6B962.9070301@qumranet.com> <45F684E7.BA47.005A.0@novell.com> <45F6BEC0.1010906@qumranet.com> <45F68E68.BA47.005A.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Return-path: 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 BTW: Please excuse my stupid confusion of uP (microprocessor) with UP (uniprocessor). Duh! >>> On Tue, Mar 13, 2007 at 11:43 AM, in message <45F68E68.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>, Gregory Haskins wrote: > >>> On Tue, Mar 13, 2007 at 11:09 AM, in message <45F6BEC0.1010906-atKUWr5tajBWk0Htik3J/w@public.gmane.org>, > Avi Kivity wrote: >> Gregory Haskins wrote: >> >>> >>> Does this sound reasonable? >>> >> >> Much simpler (at least to start with) is to send a signal. The signal >> will interrupt the guest if it is in guest mode, or if it sleeping, it >> will wake up the thread. Upon receiving the signal, the thread can >> inject an interrupt. >> >> Later on, we may wish to optimize this to avoid the signal if we're >> certain to be in guest mode, and only send it if we're asleep. > > I will investigate it from this perspective then...but I currently dont > understand how a signal delivery would cause the guest to be interrupted > (unless you guys have already put some trickery in the kvm-kmod ;). > > I can follow the logic for a uP system (I think, therefore I am.....e.g. you > cannot be both host and guest mode at the same time). However, in an SMP > system it would be conceivable for one task to be in host context, and > another to be in guest context simultaneously. If a guest was already in VM > context, wouldnt the signal being delivered simply be posted to the > pending-signals for the task and get evaluated at the next VMEXIT? The > method I was describing would actually invoke the VMEXIT to begin with. > Perhaps the best solution is a combination of both (post a signal and an IPI > which evaluates to no-op in host mode). Forgive me if I am ignorant and/or > being obtuse. :) > > Is there something I am missing? Or is there an issue with SMP with this > approach? > >> >> >>> The thing I cant quite wrap my head around is how this would work in the PV >> driver sense. For SMP, its clear...one VCPU thread might be in QEMU context >> in the LAPIC model and send the FORCE_EXIT ioctl against another VCPU to >> deliever the IPI. How does this work in a uP setup for PV? Is there some >> other thread in QEMU that might be waiting for AIO completions (etc) that >> would then be able to invoke the ioctl? Otherwise, our one and only thread >> is tied up in VM context so I dont get how it would work. >>> >> >> The scenario is a host- side kernel- mode device receiving a network >> packet and wishing to interrupt a guest. Here, the device receive >> handler is a separate thread of execution. > > I see. That makes sense. > > -Greg > > > ------------------------------------------------------------------------- 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