All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Rahul Singh <Rahul.Singh@arm.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH 5/8] xen/evtchn: don't close the static event channel.
Date: Tue, 28 Jun 2022 15:26:30 +0100	[thread overview]
Message-ID: <dbdf3bb2-edc6-e622-f17a-8819f6fcb43d@xen.org> (raw)
In-Reply-To: <DC011AED-F74B-4055-8DEE-6FFC6FC5215C@arm.com>



On 28/06/2022 14:53, Rahul Singh wrote:
> Hi Julien

Hi Rahul,

>> On 23 Jun 2022, at 4:30 pm, Julien Grall <julien@xen.org> wrote:
>>
>>
>>
>> On 23/06/2022 16:10, Rahul Singh wrote:
>>> Hi Julien,
>>>> On 22 Jun 2022, at 4:05 pm, Julien Grall <julien@xen.org> 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


  reply	other threads:[~2022-06-28 14:26 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22 14:37 [PATCH 0/8] xen/evtchn: implement static event channel signaling Rahul Singh
2022-06-22 14:37 ` [PATCH 1/8] xen/evtchn: make evtchn_bind_interdomain global Rahul Singh
2022-07-05 14:56   ` Jan Beulich
2022-07-06 11:53     ` Rahul Singh
2022-06-22 14:37 ` [PATCH 2/8] xen/evtchn: modify evtchn_alloc_unbound to allocate specified port Rahul Singh
2022-06-22 14:51   ` Julien Grall
2022-07-05 15:06     ` Jan Beulich
2022-07-11 16:08     ` Rahul Singh
2022-07-12 17:28       ` Julien Grall
2022-07-13  6:21         ` Jan Beulich
2022-07-13  9:35           ` Julien Grall
2022-07-13  9:53             ` Jan Beulich
2022-07-13 10:03               ` Bertrand Marquis
2022-07-13 10:33                 ` Julien Grall
2022-07-13 10:18               ` Julien Grall
2022-07-13 10:56                 ` Jan Beulich
2022-07-13 11:31                   ` Julien Grall
2022-07-13 12:12                     ` Bertrand Marquis
2022-07-13 12:29                       ` Julien Grall
2022-07-20  9:59                         ` Rahul Singh
2022-07-20 11:16                           ` Julien Grall
2022-07-20 13:34                             ` Jan Beulich
2022-07-21 12:50                             ` Rahul Singh
2022-07-21 13:29                               ` Julien Grall
2022-07-21 15:37                                 ` Rahul Singh
2022-07-26 17:37                                   ` Julien Grall
2022-07-28 15:37                                     ` Rahul Singh
2022-07-28 15:51                                       ` Jan Beulich
2022-07-28 20:50                                       ` Julien Grall
2022-07-29 12:35                                         ` Rahul Singh
2022-06-22 14:38 ` [PATCH 3/8] xen/evtchn: modify evtchn_bind_interdomain " Rahul Singh
2022-07-05 15:11   ` Jan Beulich
2022-07-05 15:22     ` Julien Grall
2022-07-05 15:42       ` Jan Beulich
2022-07-06 11:59         ` Rahul Singh
2022-07-06 11:57       ` Rahul Singh
2022-06-22 14:38 ` [PATCH 4/8] xen/evtchn: modify evtchn_bind_interdomain to pass domain as argument Rahul Singh
2022-07-05 15:13   ` Jan Beulich
2022-07-06 11:54     ` Rahul Singh
2022-06-22 14:38 ` [PATCH 5/8] xen/evtchn: don't close the static event channel Rahul Singh
2022-06-22 15:05   ` Julien Grall
2022-06-23 15:10     ` Rahul Singh
2022-06-23 15:30       ` Julien Grall
2022-06-23 15:33         ` Jan Beulich
2022-06-28 13:53         ` Rahul Singh
2022-06-28 14:26           ` Julien Grall [this message]
2022-06-28 14:52             ` Bertrand Marquis
2022-06-28 15:18               ` Julien Grall
2022-06-28 15:20                 ` Jan Beulich
2022-07-05 13:28                 ` Rahul Singh
2022-07-05 13:56                   ` Julien Grall
2022-07-06 10:42                     ` Rahul Singh
2022-07-06 11:04                       ` Julien Grall
2022-07-06 11:33                         ` Juergen Gross
2022-07-07 12:45                           ` Rahul Singh
2022-07-05 15:17   ` Jan Beulich
2022-07-05 15:26   ` Jan Beulich
2022-07-05 15:33     ` Jan Beulich
2022-06-22 14:38 ` [PATCH 6/8] xen/evtchn: don't set notification in evtchn_bind_interdomain() Rahul Singh
2022-07-05 15:23   ` Jan Beulich
2022-06-22 14:38 ` [PATCH 7/8] xen: introduce xen-evtchn dom0less property Rahul Singh
2022-08-05 16:10   ` Rahul Singh
2022-08-05 16:14     ` Julien Grall
2022-08-08  9:17       ` Rahul Singh
2022-06-22 14:38 ` [PATCH 8/8] xen/arm: introduce new xen,enhanced property value Rahul Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dbdf3bb2-edc6-e622-f17a-8819f6fcb43d@xen.org \
    --to=julien@xen.org \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Rahul.Singh@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.