RE: [Xen-devel] Re: event delay issue on SMP machine when xen0 isSMPenabled

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Li, Xin B
>Sent: 2005年12月9日 17:18
>
>
>>>You always remember a good reason not to do something after
>>>sending the
>>>email. :-)
>>>
>>>IPIs and VIRQs must be processed by their home vcpu. Hence we do need
>>>to limit evtchn processing to the current bound vcpu, and that leads
>>>(currently) to the problem you see.
>>>
>>>So I think the right fix is just to fix unmask_evtchn(). Maybe
>>>you guys
>>>want to send a patch to move it into evtchn.c and fix it to send to
>>>cpu_from_evtchn(evtchn)?
>>>
>>
>>Since evtchn code is critical to xen, we are very careful when finding
>>any possible fixes :-)
>>Why not turn on cpu_evtchn_mask by default, and when calling
>>bind_evtchn_to_cpu, we turn off it on other cpus.
>>
>
>Or when binding interdomain evtchn in xen0, we turn on it on each cpu?
>-Xin

Another way may be to add a new EVTCHNOP_resend_event. Previously all unmask 
operations are done in guest, because existing code only modifies mask of 
current vcpu. If port to be unmasked is bound to other vcpu, it's uneasy to 
promise sanity in guest when trying to modify mask of another vcpu. By 
introducing new EVTCHNOP, we may take unmask_evtchn sequence as:

synch_clear_bit(port, &s->evtchn_mask[0]);
if (bound vcpu == smp_processor_id[]) {
        existing code
else {
        HYPERVISOR_event_channel_op(op.cmd = EVTCHNOP_resend_event, 
op.vcpu=bound vcpu, op.port=port)
}

Later Xen will not translate port to remote one since it's local domain, and 
try to re-send event to target vcpu. In this way, the missing event will be 
seen by target vcpu again. Is it the way? ;-)

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel