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

[Bhupinder Thakur <bhupinder.thakur@xxxxxxxxxx>]

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@xxxxxxxxxx> wrote:
> Hi,
>
> On 6 March 2017 at 16:24, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 06.03.17 at 11:44, <bhupinder.thakur@xxxxxxxxxx> wrote:
>>> On 6 March 2017 at 13:45, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>>> On 05.03.17 at 13:39, <julien.grall@xxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel