Fwd: Re: Status of SMP?

["Gregory Haskins" <ghaskins-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.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 <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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