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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id F248FC433EF for ; Tue, 28 Jun 2022 14:26:47 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.357141.585578 (Exim 4.92) (envelope-from ) id 1o6CAl-0002mF-It; Tue, 28 Jun 2022 14:26:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 357141.585578; Tue, 28 Jun 2022 14:26:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o6CAl-0002m8-GG; Tue, 28 Jun 2022 14:26:35 +0000 Received: by outflank-mailman (input) for mailman id 357141; Tue, 28 Jun 2022 14:26:33 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o6CAj-0002ly-NQ for xen-devel@lists.xenproject.org; Tue, 28 Jun 2022 14:26:33 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o6CAj-0000Pt-Bf; Tue, 28 Jun 2022 14:26:33 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=[192.168.2.252]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o6CAj-0005ra-57; Tue, 28 Jun 2022 14:26:33 +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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=YBp3rjCoK/7YhduO4MDknePhI7n5ZJucvRKCk30BpwU=; b=7D4XBBMVSZCCF568nzM+frKAj2 lS21T2IkwlOU2iXIm4RP2+Mupw4KsxFEteUlvgoyXZ3IVYDzmNbEDGK/6mwArRH+TqnNYD+njIXDa W06iRfWhJtFJv8DhWtEDojBSQf53MG/PgRc9yRNl6aedE4UnIUR6wvr0fgvqaS08HpII=; Message-ID: Date: Tue, 28 Jun 2022 15:26:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 5/8] xen/evtchn: don't close the static event channel. To: Rahul Singh Cc: xen-devel , Bertrand Marquis , Stefano Stabellini , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Jan Beulich , Wei Liu References: <91656930b5bfd49e40ff5a9d060d7643e6311f4f.1655903088.git.rahul.singh@arm.com> <7403EAA7-67A4-4A8D-835E-6015463B9016@arm.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 28/06/2022 14:53, Rahul Singh wrote: > Hi Julien Hi Rahul, >> On 23 Jun 2022, at 4:30 pm, Julien Grall wrote: >> >> >> >> On 23/06/2022 16:10, Rahul Singh wrote: >>> Hi Julien, >>>> On 22 Jun 2022, at 4:05 pm, Julien Grall wrote: >>>> >>>> Hi, >>>> >>>> On 22/06/2022 15:38, Rahul Singh wrote: >>>>> Guest can request the Xen to close the event channels. Ignore the >>>>> request from guest to close the static channels as static event channels >>>>> should not be closed. >>>> >>>> Why do you want to prevent the guest to close static ports? The problem I can see is... >>> As a static event channel should be available during the lifetime of the guest we want to prevent >>> the guest to close the static ports. >> I don't think it is Xen job to prevent a guest to close a static port. If the guest decide to do it, then it will just break itself and not Xen. > > It is okay for the guest to close a port, port is not allocated by the guest in case of a static event channel. As I wrote before, the OS will need to know that the port is statically allocated when initializing the port (we don't want to call the hypercall to bind the event channel). By extend, the OS should be able to know that when closing it and skip the hypercall. > Xen has nothing to do for close the static event channel and just return 0. Xen would not need to be modified if the OS was doing the right (i.e. no calling close). So it is still unclear why papering over the issue in Xen is the best solution. Cheers, -- Julien Grall