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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.03.17 at 11:16, <bhupinder.thakur@xxxxxxxxxx> wrote:
> On 4 March 2017 at 02:43, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> wrote:
>> 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.
> 
> I think there was never a use case earlier to generate events from the
> Xen itself to the guest. The event generation always happened on
> behalf of a guest via evtchn_send(), which was invoked through a
> hypercall by the guest.

This is not true: All interrupts being converted to events go this
route, without any hypercall involved. Same for signaling qemu
to do emulation of an emulated device (memory of port) access.

> To disallow a guest from sending an event via
> an event channel which is bound to Xen, there is a check in
> evtchn_send() to check if it is a xen bound channel and if it is then
> disallow sending an event via that channel because that channel is
> meant only for Xen.

As said in reply to your patch - I think you got directions mixed up
here: You talk about Xen sending an event to a guest, but at the
same time you fiddle with code preventing guests from sending
events to Xen.

> For pl011 emulation, there is a requirement for Xen to generate the
> event to dom0 when there is data for dom0 to read in the ring buffer.

This is not different from hardware signaling the need for service
via an interrupt, which - always for PV guests, sometimes for HVM
ones - is being converted to an event.

> Since I am using a Xen bound channel so that Xen can receive events
> from dom0 when there is data for Xen to read, the above mentioned
> check would not allow the event to be sent to dom0.

Now here you come to talk about the direction which indeed is not
allowed. But breaking out part of the function won't help you, as
the new (raw) function then mustn't be called as a result of some
guest's request (hypercall or whatever), which includes Dom0.

> Since this event is required to be generated from Xen only, it is safe
> to allow to send the event from a xen bound channel. That is why I
> introduced a new function raw_evtchn_send() to allow Xen to do that
> while still keeping that restriction for the guests who use
> evtchn_send() as it is today.

And now it becomes confusing again: Yet another time you talk about
Xen sending the event. Please can you cleanly separate both directions
of event flow, and talk only about the relevant one in the respective
contexts?

Jan


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