WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: event delay issue on SMP machine when xen0 is SMP enabled
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Fri, 9 Dec 2005 17:08:27 +0800
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Fri, 09 Dec 2005 09:09:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX8nHEjlG+38u2iTdubTrLZ9qM19wAAyS/w
Thread-topic: [Xen-devel] Re: event delay issue on SMP machine when xen0 is SMP enabled
>>> BTW, why vcpu other than vcpu0 won't handle event by default?
>>
>> We could allow any vcpu to process any pending 
>notifications. It would 
>> mean vcpus outside an irq's affinity set could end up processing an 
>> interrupt and I'm not sure if that's a good thing. It would actually 
>> slightly simplify evtchn.c though (no need to apply a 
>per-cpu mask to 
>> the event-channel port array).
>
>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.

Thanks
-Xin

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

<Prev in Thread] Current Thread [Next in Thread>