Fwd: Re: Status of SMP?

Gregory Haskins
2007-03-13T15:47:21Z

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