From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F652C71155 for ; Wed, 2 Dec 2020 19:03:55 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C4BA2224C for ; Wed, 2 Dec 2020 19:03:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C4BA2224C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.42977.77329 (Exim 4.92) (envelope-from ) id 1kkXPY-0005jT-S5; Wed, 02 Dec 2020 19:03:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 42977.77329; Wed, 02 Dec 2020 19:03:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kkXPY-0005jM-OX; Wed, 02 Dec 2020 19:03:32 +0000 Received: by outflank-mailman (input) for mailman id 42977; Wed, 02 Dec 2020 19:03:31 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kkXPX-0005jH-E2 for xen-devel@lists.xenproject.org; Wed, 02 Dec 2020 19:03:31 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kkXPU-0000zm-DC; Wed, 02 Dec 2020 19:03:28 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kkXPU-0002Mw-3W; Wed, 02 Dec 2020 19:03:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=T432UGitHsRICyXBtYhUNS3QUhL8d5TafwM77KhXsGQ=; b=Z7GrOVkr3clPfUxXianyTNk/R/ wUuVDDZ2ZcEYWxpGhFcYUOsJdLBY0XN+vRRyrdEu4nmDwn5cFKh30oiARuc7+cYagFxGPfI7NLZlD Pq/5WTbjitNbfMQo/i+pCYQDIhu4rRywhvbo9iLQ+iiZGWGfgiAMT3l+rW3xuHvow/J8=; Subject: Re: [PATCH v3 1/5] evtchn: drop acquiring of per-channel lock from send_guest_{global,vcpu}_virq() To: Jan Beulich , "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , George Dunlap , Ian Jackson , Wei Liu , Stefano Stabellini References: <9d7a052a-6222-80ff-cbf1-612d4ca50c2a@suse.com> From: Julien Grall Message-ID: <70170293-a9a7-282a-dde6-7ed73fc2da48@xen.org> Date: Wed, 2 Dec 2020 19:03:26 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Hi Jan, On 23/11/2020 13:28, Jan Beulich wrote: > The per-vCPU virq_lock, which is being held anyway, together with there > not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[] > is zero, provide sufficient guarantees. I agree that the per-vCPU virq_lock is going to be sufficient, however dropping the lock also means the event channel locking is more complex to understand (the long comment that was added proves it). In fact, the locking in the event channel code was already proven to be quite fragile, therefore I think this patch is not worth the risk. Cheers, -- Julien Grall