Re: [PATCH 03/11] xen/arm: vpl011: Refactor evtchn_send in Xen to allow sending events from a xen bound channel

From: Bhupinder Thakur <bhupinder.thakur@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	GeorgeDunlap <george.dunlap@eu.citrix.com>,
	AndrewCooper <Andrew.Cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel@lists.xenproject.org, nd@arm.com
Subject: Re: [PATCH 03/11] xen/arm: vpl011: Refactor evtchn_send in Xen to allow sending events from a xen bound channel
Date: Tue, 28 Mar 2017 15:13:24 +0530	[thread overview]
Message-ID: <CACtJ1JSXkK5PHLaKi7WL_VjEAp5Sk-Yzje3bj3dwtVs7PVuVkQ@mail.gmail.com> (raw)
In-Reply-To: <CACtJ1JSsY1YtDkOcxk5cKVyPD8yGDW3YUOrGDD4c3xPLTxHorg@mail.gmail.com>

Hi,

Now I am using notify_via_xen_event_channel() to send the vpl011
events to dom0. So no changes are required in evtchn_send() and this
patch can be dropped.

Regards,
Bhupinder

On 6 March 2017 at 16:42, Bhupinder Thakur <bhupinder.thakur@linaro.org> wrote:
> Hi,
>
> On 6 March 2017 at 16:24, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 06.03.17 at 11:44, <bhupinder.thakur@linaro.org> wrote:
>>> On 6 March 2017 at 13:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 05.03.17 at 13:39, <julien.grall@arm.com> wrote:
>>>>> On 02/21/2017 11:26 AM, 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,
>>>>>> 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
>>>>>> xen consumer check. Xen uses the raw_evtchm_send() version to send the event thus
>>>>>> bypassing the check.
>>>>
>>>> Why would Xen want to send an event it is itself the consumer of?
>>>> Surely there are better ways to communicate state internally? The
>>>> more that you say you want the event sent to Dom0...
>>>>
>>> As a consumer, Xen receives event from dom0. It also needs to send
>>> events to dom0 to indicate that there is data in the ring buffer for
>>> dom0 to read. I am using a xen bound event channel for
>>> sending/receiving events to/from dom0. I added a new function
>>> raw_evtchn_send() to allow Xen to send events to dom0 without doing
>>> the is_xen_consumer check. Note that this check is still there in
>>> evtchn_send() to disallow guests to raise events on the xen bound
>>> channel.
>>
>> I can see why Xen needs to send events; I can't see why Dom0 couldn't
>> simply make a hypercall instead of sending an event if it needs to signal
>> something.
>>
> We decided to reuse the same PV console interface for pl011 as used
> for PV console in xenconsole running on dom0, which is events/ring
> buffer based. From xenconsole point of view, there is no difference in
> terms of handling a pl011 console and a PV console.
>
>> Jan
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel