BTW: Please excuse my stupid confusion of uP (microprocessor) with UP (uniprocessor). Duh!
>>> On Tue, Mar 13, 2007 at 11:43 AM, in message <[EMAIL PROTECTED]>, Gregory Haskins wrote: > >>> On Tue, Mar 13, 2007 at 11:09 AM, in message <[EMAIL PROTECTED]>, > Avi Kivity <[EMAIL PROTECTED]> 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 _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
