From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PROPOSAL] Event channel for SMP-VMs: per-vCPU or per-OS? Date: Tue, 29 Oct 2013 10:52:57 +0000 Message-ID: <526F9389.1000504@eu.citrix.com> References: <526E87E5.9000105@citrix.com> <526F7D9202000078000FD795@nat28.tlf.novell.com> <526F8F3802000078000FD7FA@nat28.tlf.novell.com> <526F947E02000078000FD829@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vb6v0-0007A4-0N for xen-devel@lists.xenproject.org; Tue, 29 Oct 2013 10:53:02 +0000 In-Reply-To: <526F947E02000078000FD829@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Luwei Cheng , xen-devel@lists.xenproject.org, wei.liu2@citrix.com, david.vrabel@citrix.com, roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 10/29/2013 09:57 AM, Jan Beulich wrote: >>>> On 29.10.13 at 10:49, Luwei Cheng wrote: >> On Tue, Oct 29, 2013 at 5:34 PM, Jan Beulich wrote: >>>>>> On 29.10.13 at 10:02, Luwei Cheng wrote: >>>> On Tue, Oct 29, 2013 at 4:19 PM, Jan Beulich wrote: >>>>>>>> On 29.10.13 at 03:56, Luwei Cheng wrote: >>>>>> Hmm.. though all vCPUs can serve the events, the hypervisor delivers the >>>>>> event to only "one" vCPU at at time, so only that vCPU can see this event. >>>>>> Analytically no race condition will be introduced. >>>>> >>>>> No - an event is globally pending (at least in the old model, the >>>>> situation is better with the new FIFO model), i.e. if more than >>>>> one of the guest's vCPU-s allowed to service it would be looking >>>>> at it simultaneously, they'd still need to arbitrate which one >>>>> ought to handle it. >>>>> >>>>> So your proposed extension might need to be limited to the >>>>> FIFO model. >>>> >>>> Thanks for your reply. Yes, you are right. My prior description was >>>> incorrect. >>>> When there are more than one vCPUs picking the event, even without >>>> arbitrary, will it cause "correctness" problem? After the event is >>> served by >>>> the first entered vCPU, and the rest vCPUs just have noting to do in the >>>> event handler (no much harm). >>> >>> That really depends on the handler. Plus it might be a performance >>> and/or latency issue to run handlers that don't need to be run. >> >> I think the situation is much like IO-APIC routing in physical SMP >> systems: > > Indeed, yet you draw the wrong conclusion. > >> in logical destination mode, all processors can serve I/O interrupts. > > But only one gets delivered any individual instance - there is > arbitration being done in hardware. Xen should be able to arbitrate which one gets the actual event delivery, right? So the only risk would be that another vcpu would notice the pending interrupt and handle it itself. -George