All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, jgross@suse.com,
	Bertrand.Marquis@arm.com, Volodymyr_Babchuk@epam.com,
	Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>
Subject: Re: [XEN PATCH v2 2/5] xen: export get_free_port
Date: Tue, 25 Jan 2022 09:22:05 +0100	[thread overview]
Message-ID: <14af544d-0d20-9b58-4d70-5f5086ece032@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2201241652330.27308@ubuntu-linux-20-04-desktop>

On 25.01.2022 02:10, Stefano Stabellini wrote:
> On Sun, 23 Jan 2022, Julien Grall wrote:
>>> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
>>> index da88ad141a..5b0bcaaad4 100644
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -232,7 +232,7 @@ int evtchn_allocate_port(struct domain *d, evtchn_port_t
>>> port)
>>>       return 0;
>>>   }
>>>   -static int get_free_port(struct domain *d)
>>> +int get_free_port(struct domain *d)
>>
>> I dislike the idea to expose get_free_port() (or whichever name we decide)
>> because this can be easily misused.
>>
>> In fact looking at your next patch (#3), you are misusing it as it is meant to
>> be called with d->event_lock. I know this doesn't much matter
>> in your situation because this is done at boot with no other domains running
>> (or potentially any event channel allocation). However, I still think we
>> should get the API right.
>>
>> I am also not entirely happy of open-coding the allocation in domain_build.c.
>> Instead, I would prefer if we provide a new helper to allocate an unbound
>> event channel. This would be similar to your v1 (I still need to review the
>> patch though).
> 
> I am happy to go back to v1 and address feedback on that patch. However,
> I am having difficulties with the implementation. Jan pointed out:
> 
> 
>>> -
>>> -    chn->state = ECS_UNBOUND;
>>
>> This cannot be pulled ahead of the XSM check (or in general anything
>> potentially resulting in an error), as check_free_port() relies on
>> ->state remaining ECS_FREE until it is known that the calling function
>> can't fail anymore.
> 
> This makes it difficult to reuse _evtchn_alloc_unbound for the
> implementation of evtchn_alloc_unbound. In fact, I couldn't find a way
> to do it.
> 
> Instead, I just create a new public function called
> "evtchn_alloc_unbound" and renamed the existing funtion to
> "_evtchn_alloc_unbound" (this to addresses Jan's feedback that the
> static function should be the one starting with "_"). So the function
> names are inverted compared to v1.
> 
> Please let me know if you have any better suggestions.
> 
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index da88ad141a..c6b7dd7fbd 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -18,6 +18,7 @@
>  
>  #include <xen/init.h>
>  #include <xen/lib.h>
> +#include <xen/err.h>
>  #include <xen/errno.h>
>  #include <xen/sched.h>
>  #include <xen/irq.h>
> @@ -284,7 +285,27 @@ void evtchn_free(struct domain *d, struct evtchn *chn)
>      xsm_evtchn_close_post(chn);
>  }
>  
> -static int evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
> +struct evtchn *evtchn_alloc_unbound(struct domain *d, domid_t remote_dom)
> +{
> +    struct evtchn *chn;
> +    int port;
> +
> +    if ( (port = get_free_port(d)) < 0 )
> +        return ERR_PTR(port);
> +    chn = evtchn_from_port(d, port);
> +
> +    evtchn_write_lock(chn);
> +
> +    chn->state = ECS_UNBOUND;
> +    chn->u.unbound.remote_domid = remote_dom;
> +    evtchn_port_init(d, chn);
> +
> +    evtchn_write_unlock(chn);
> +
> +    return chn;
> +}
> +
> +static int _evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
>  {
>      struct evtchn *chn;
>      struct domain *d;

Instead of introducing a clone of this function (with, btw, still
insufficient locking), did you consider simply using the existing
evtchn_alloc_unbound() as-is, i.e. with the caller passing
evtchn_alloc_unbound_t *?

Jan



  reply	other threads:[~2022-01-25  8:22 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13  0:58 [XEN PATCH v2 0/5] dom0less PV drivers Stefano Stabellini
2022-01-13  0:58 ` [XEN PATCH v2 1/5] xen: introduce xen,enhanced dom0less property Stefano Stabellini
2022-01-13  8:29   ` Bertrand Marquis
2022-01-14  1:21     ` Stefano Stabellini
2022-01-13  9:09   ` Luca Fancellu
2022-01-13 23:02     ` Stefano Stabellini
2022-01-13  0:58 ` [XEN PATCH v2 2/5] xen: export get_free_port Stefano Stabellini
2022-01-13  8:19   ` Jan Beulich
2022-01-14  1:20     ` Stefano Stabellini
2022-01-14  7:02       ` Jan Beulich
2022-01-23 11:02   ` Julien Grall
2022-01-25  1:10     ` Stefano Stabellini
2022-01-25  8:22       ` Jan Beulich [this message]
2022-01-25 18:02         ` Julien Grall
2022-01-25 22:49         ` Stefano Stabellini
2022-01-25 23:14           ` Julien Grall
2022-01-26  1:03             ` Stefano Stabellini
2022-01-26  7:30               ` Jan Beulich
2022-01-26  9:50                 ` Julien Grall
2022-01-27  1:50                   ` Stefano Stabellini
2022-01-27  9:51                     ` Julien Grall
2022-01-27 12:07                       ` Jan Beulich
2022-01-27 13:31                         ` Julien Grall
2022-01-28  1:38                           ` Stefano Stabellini
2022-01-28  7:09                             ` Jan Beulich
2022-01-26  7:26           ` Jan Beulich
2022-01-13  0:58 ` [XEN PATCH v2 3/5] xen/arm: configure dom0less domain for enabling xenstore after boot Stefano Stabellini
2022-01-13 10:15   ` Bertrand Marquis
2022-01-23 11:06     ` Julien Grall
2022-01-26  1:02       ` Stefano Stabellini
2022-01-13  0:58 ` [XEN PATCH v2 4/5] xenstored: send an evtchn notification on introduce_domain Stefano Stabellini
2022-01-13 10:18   ` Bertrand Marquis
2022-01-13  0:58 ` [XEN PATCH v2 5/5] tools: add example application to initialize dom0less PV drivers Stefano Stabellini
2022-01-13 10:30   ` Bertrand Marquis

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=14af544d-0d20-9b58-4d70-5f5086ece032@suse.com \
    --to=jbeulich@suse.com \
    --cc=Bertrand.Marquis@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=stefano.stabellini@xilinx.com \
    --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.