From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Bhupinder Thakur <bhupinder.thakur@linaro.org>
Cc: xen-devel@lists.xenproject.org,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 03/11] xen/arm: vpl011: Refactor evtchn_send in Xen to allow sending events from a xen bound channel
Date: Fri, 3 Mar 2017 16:13:55 -0500 [thread overview]
Message-ID: <20170303211355.GF18423@char.us.ORACLE.com> (raw)
In-Reply-To: <1487676368-22356-4-git-send-email-bhupinder.thakur@linaro.org>
On Tue, Feb 21, 2017 at 04:56:00PM +0530, Bhupinder Thakur wrote:
> Breakup evtchn_send() to allow sending events for a Xen bound channel. Currently,
> there is a check in evtchn_send() i.e. is_consumer_xen() that if the event channel
> is bound to a xen consumer then event generation is not allowed for that channel.
> This check is to disallow a guest from raising an event via this channel. However,
Did any code archeology help in idenfitying why this was done this way?
You should explain why it was done - what was the use case , and why
your change will not change this semantic.
> it should allow Xen to send a event via this channel as it is required for sending
> vpl011 event to the dom0.
>
> This change introduces a new function raw_evtchn_send() which sends the event
> without this check. The current evtchn_send() calls this function after doing the
.. and without taking a lock? Why?
> xen consumer check. Xen uses the raw_evtchm_send() version to send the event thus
> bypassing the check.
>
> Signed-off-by: Bhupinder Thakur <bhupinder.thakur@linaro.org>
> ---
> xen/common/event_channel.c | 49 ++++++++++++++++++++++++++++++++++------------
> xen/include/xen/event.h | 6 ++++++
> 2 files changed, 42 insertions(+), 13 deletions(-)
>
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 638dc5e..4b039f3 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -27,6 +27,7 @@
> #include <xen/keyhandler.h>
> #include <xen/event_fifo.h>
> #include <asm/current.h>
> +#include <xen/domain_page.h>
>
> #include <public/xen.h>
> #include <public/event_channel.h>
> @@ -650,25 +651,21 @@ static long evtchn_close(struct domain *d1, int port1, bool_t guest)
> return rc;
> }
>
> -int evtchn_send(struct domain *ld, unsigned int lport)
> +int raw_evtchn_send(struct domain *ld, unsigned int lport, void *data)
> {
> struct evtchn *lchn, *rchn;
> struct domain *rd;
> - int rport, ret = 0;
> + int rport, ret=0;
Please that code as is.
>
> - if ( !port_is_valid(ld, lport) )
> - return -EINVAL;
> -
> - lchn = evtchn_from_port(ld, lport);
> -
> - spin_lock(&lchn->lock);
> -
> - /* Guest cannot send via a Xen-attached event channel. */
> - if ( unlikely(consumer_is_xen(lchn)) )
> + if ( !data )
> {
> - ret = -EINVAL;
> - goto out;
> + if ( !port_is_valid(ld, lport) )
> + return -EINVAL;
> + lchn = evtchn_from_port(ld, lport);
> + spin_lock(&lchn->lock);
That won't do. Please keep the format of the old code as much
as possible (hint: Those newlines).
> }
> + else
> + lchn = (struct evtchn *)data;
>
> ret = xsm_evtchn_send(XSM_HOOK, ld, lchn);
> if ( ret )
> @@ -696,6 +693,32 @@ int evtchn_send(struct domain *ld, unsigned int lport)
> }
>
> out:
> + if ( !data )
> + spin_unlock(&lchn->lock);
> +
> + return ret;
> +}
> +
> +int evtchn_send(struct domain *ld, unsigned int lport)
> +{
> + struct evtchn *lchn;
> + int ret;
> +
> + if ( !port_is_valid(ld, lport) )
> + return -EINVAL;
> +
> + lchn = evtchn_from_port(ld, lport);
> +
> + spin_lock(&lchn->lock);
> +
> + if ( unlikely(consumer_is_xen(lchn)) )
> + {
> + printk("evtchn_send failed to send via xen event channel\n");
No. Please do not.
> + return -EINVAL;
> + }
> +
> + ret = raw_evtchn_send(ld, lport, lchn);
> +
> spin_unlock(&lchn->lock);
>
> return ret;
> diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
> index 5008c80..9bd17db 100644
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -45,6 +45,12 @@ void send_guest_pirq(struct domain *, const struct pirq *);
> /* Send a notification from a given domain's event-channel port. */
> int evtchn_send(struct domain *d, unsigned int lport);
>
> +/*
> + * This function is same as evntchn_send() except it does not do xen consumer check
> + * to allow the events to be sent from xen bound channels.
And it also looks to ignore the locking? Could you explain why?
> + */
> +int raw_evtchn_send(struct domain *ld, unsigned int lport, void *data);
> +
> /* Bind a local event-channel port to the specified VCPU. */
> long evtchn_bind_vcpu(unsigned int port, unsigned int vcpu_id);
>
> --
> 2.7.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-03-03 21:14 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 11:25 [PATCH 00/11] pl011 emulation support in Xen Bhupinder Thakur
2017-02-21 11:25 ` [PATCH 01/11] xen/arm: vpl011: Add pl011 uart emulation " Bhupinder Thakur
2017-02-26 21:37 ` Julien Grall
2017-03-03 19:19 ` Julien Grall
2017-03-21 13:27 ` Bhupinder Thakur
2017-03-21 19:38 ` Julien Grall
2017-03-23 9:44 ` Bhupinder Thakur
2017-03-23 13:51 ` Julien Grall
2017-03-03 19:59 ` Konrad Rzeszutek Wilk
2017-03-05 1:04 ` Julien Grall
2017-03-06 14:22 ` Konrad Rzeszutek Wilk
2017-03-05 1:15 ` Julien Grall
2017-03-05 11:59 ` Julien Grall
2017-03-22 5:50 ` Bhupinder Thakur
2017-03-05 12:12 ` Julien Grall
2017-03-23 9:14 ` Bhupinder Thakur
2017-03-23 14:16 ` Julien Grall
2017-03-24 10:39 ` Bhupinder Thakur
2017-02-21 11:25 ` [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup Bhupinder Thakur
2017-03-03 20:02 ` Konrad Rzeszutek Wilk
2017-03-24 6:58 ` Bhupinder Thakur
2017-03-05 12:35 ` Julien Grall
2017-03-06 8:06 ` Jan Beulich
2017-03-06 11:42 ` Julien Grall
2017-03-06 12:41 ` Jan Beulich
2017-03-06 13:21 ` Julien Grall
2017-03-06 13:48 ` Jan Beulich
2017-03-08 14:45 ` Julien Grall
2017-03-08 15:21 ` Jan Beulich
2017-03-08 18:22 ` Stefano Stabellini
2017-04-11 14:38 ` Bhupinder Thakur
2017-04-11 22:07 ` Stefano Stabellini
2017-04-14 7:12 ` Bhupinder Thakur
2017-04-19 18:43 ` Stefano Stabellini
2017-03-06 14:48 ` George Dunlap
2017-03-08 13:52 ` Julien Grall
2017-03-24 7:31 ` Bhupinder Thakur
2017-02-21 11:26 ` [PATCH 03/11] xen/arm: vpl011: Refactor evtchn_send in Xen to allow sending events from a xen bound channel Bhupinder Thakur
2017-03-03 21:13 ` Konrad Rzeszutek Wilk [this message]
2017-03-06 10:16 ` Bhupinder Thakur
2017-03-06 10:35 ` Jan Beulich
2017-03-05 12:39 ` Julien Grall
2017-03-06 8:15 ` Jan Beulich
2017-03-06 10:44 ` Bhupinder Thakur
2017-03-06 10:54 ` Jan Beulich
2017-03-06 11:12 ` Bhupinder Thakur
2017-03-28 9:43 ` Bhupinder Thakur
2017-02-21 11:26 ` [PATCH 04/11] xen/arm: vpl011: Enable vpl011 emulation for a domain in Xen Bhupinder Thakur
2017-03-03 21:47 ` Konrad Rzeszutek Wilk
2017-03-05 12:46 ` Julien Grall
2017-03-06 8:27 ` Jan Beulich
2017-02-21 11:26 ` [PATCH 05/11] xen/arm: vpl011: Initialize nr_spis in vgic_init in Xen to atleast 1 Bhupinder Thakur
2017-03-03 20:49 ` Konrad Rzeszutek Wilk
2017-03-05 12:51 ` Julien Grall
2017-03-16 6:50 ` Bhupinder Thakur
2017-03-16 8:24 ` Julien Grall
2017-03-16 10:31 ` Bhupinder Thakur
2017-03-16 13:24 ` Julien Grall
2017-03-20 16:29 ` Bhupinder Thakur
2017-02-21 11:26 ` [PATCH 06/11] xen/arm: vpl011: Add a new pl011 uart node in the guest DT in the toolstack Bhupinder Thakur
2017-03-03 20:15 ` Konrad Rzeszutek Wilk
2017-03-03 21:03 ` Konrad Rzeszutek Wilk
2017-03-05 12:59 ` Julien Grall
2017-03-05 13:04 ` Julien Grall
2017-03-14 13:00 ` Wei Liu
2017-02-21 11:26 ` [PATCH 07/11] xen/arm: vpl011: Add two new vpl011 parameters to xenstore Bhupinder Thakur
2017-03-03 20:58 ` Konrad Rzeszutek Wilk
2017-03-28 7:49 ` Bhupinder Thakur
2017-02-21 11:26 ` [PATCH 08/11] xen/arm: vpl011: Allocate a new PFN in the toolstack and pass to Xen using a hvm call Bhupinder Thakur
2017-03-03 20:51 ` Konrad Rzeszutek Wilk
2017-03-05 13:07 ` Julien Grall
2017-02-21 11:26 ` [PATCH 09/11] xen/arm: vpl011: Modify domain_create_ring in xenconsole to map the ring buffer and event channel Bhupinder Thakur
2017-03-03 21:46 ` Konrad Rzeszutek Wilk
2017-02-21 11:26 ` [PATCH 10/11] xen/arm: vpl011: Modify handle_ring_read and buffer_append to read/append vpl011 data Bhupinder Thakur
2017-03-03 21:06 ` Konrad Rzeszutek Wilk
2017-02-21 11:26 ` [PATCH 11/11] xen/arm: vpl011: Modify handle_tty_read in xenconsole to redirect user data to vpl011 IN ring buffer Bhupinder Thakur
2017-03-03 21:17 ` Konrad Rzeszutek Wilk
2017-03-03 20:23 ` [PATCH 00/11] pl011 emulation support in Xen Konrad Rzeszutek Wilk
2017-03-03 21:15 ` Konrad Rzeszutek Wilk
2017-03-14 7:44 ` Bhupinder Thakur
2017-03-05 11:46 ` Julien Grall
2017-03-14 7:47 ` Bhupinder Thakur
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=20170303211355.GF18423@char.us.ORACLE.com \
--to=konrad.wilk@oracle.com \
--cc=bhupinder.thakur@linaro.org \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.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.